实话说，你要弄清楚哪部分卡；
1 、就算 ts 切片，你服务器带宽就 5M ，10 个人在线看，还不是照样卡吗？
2 、不知道你后端业务是怎样的，nginx 的话大文件会自动 range ，类似 ts 切片，一次加载一部分，大多数浏览器都支持 range 请求；但和第一点一样，带宽如何？
3 、一个视频几百兆，首先要做的就是针对请求限流吧？次要就是看带宽是否能支持；
4 、其实国内 CDN 大多按量计费，你这种场景非常适合上 CDN ，费用起码比你加大服务器带宽要便宜的多。
5 、如果一毛不拔，建议上传第三方视频平台。

我之前也试过，后来马上改了；
1 、部分产品允许超售，此时就会出现-1 的情况，无法分辨是超售了还是无限；
2 、设置为 NULL ，业务代码判断的时候需要单独区分判断，可以这样做，但对后续业务代码不友善；
3 、增加栏位，设定为是否不限库存；

最终我们选择的是第三点；
因为产品允许 超售|库存|不限；
包括后来增加的功能，部分产品需要二次询价，比方 A 给我们一个基本价，库存 10 ，超出库存的要二次确认，我们有单就飞过去，超出库存部分是否能做由他们决定，这种的话业务上会设置为库存产品|允许超售；
1 、因为业务需要统计还剩多少没卖，所以不能设定为不限库存产品；
2 、由于超出时候不是不能卖，只是流程上需要供应二次确认，所以只能设定为 可超售。

所以建议你还是加多个栏位进行判断。
BTW：
我们有些直连对接的分销，业务关系，我们不会反回这种产品究竟是 可超 /不可超 /库存数量这些的，一般情况下可超或库存大于 999 的直接返回 999 ；

@void1900
换种说法可能更容易理解；
nginx/httpd 如何知道这个文件需要转发给 phpfpm 还是直接读取返回呢？
这时候一般就几种方式；
1 、根据后缀来判断是否 php 文件；（其实就是#15 说的“解析文件时要么根据 MIME （后缀名也算）”
2 、根据目录转发请求；这种就和你所说的，和 mime 毫无关联
3 、全部请求转发，相当于 nginx 进行反代或均衡或缓存等；如 webman 框架，框架自身自带处理静态文件，上级的 nginx 做负载。

@jeeyong 你是在说某程吗，之前研究过携某的反爬，发现他们会通过浏览器特性来判断爬虫，
一但判定为爬虫，会直接返回相对高的价格，甚至后来直接不管是不是爬虫，列表价直接返回浮动价，只有预定价才会返回真实价，前端就弹出恭喜你，价格降低 xxx 之类的。

@void1900
常规场景下他说的没错，
apache 太久没碰不确认，但依稀记得是通过 AddType 添加 PHP 的 mime 进去的
nginx 的话就是看配置.php 后缀然后转发 php-fpm

当然也有场景是 php 直接监听端口，nginx 按目录请求转发到端口，这种就和 mime 没关系。


回到 LZ 的问题，
Nginx 通过 phpfpm 转发的话 fpm 挂了，那么会产生 5XX 错误，不会反回源码；
一般反回源码的情况是 Nginx/Httpd 没配置好的时候（即没把解析 PHP 配置好），就会出现反回源码。

站群、咨询类的 PHP 居多，因为真快也不用考虑效率。
业务系统类的，PHP 占有率不算高，因为这一块真要用 PHP 去堆砌，暂时发现性能跟得上的只有 swoole 和 workman，
但实话说 workman 或 swoole 的开发思想上和平常的真不同，特别是 swoole 。

使用者的心态：
1 、你开源了就必须对项目和使用者负责；
2 、我现在使用了你的项目，出了问题，我需要的是第一时间解决，而不是参考一大堆资料才找到答案。

开源者的心态：
1 、我只是把我的思路开放供参考；
2 、线上服务使用了出现问题可以提 issue，回复效率取决于我的时间。

能理解使用者的心态，但不支持使用者的这种行为；
首先他需要弄明白什么叫 “商业支持”，大家的时间都很宝贵，
并且漫无目的的喷码不是解决问题的方法。
对于这种人，没必要回复，实在气不过，直接把记录截图放到项目首页作为申明。

好奇问问，JS 属于吗？
在服务端，有 nodeJs
在 web 端，有 vue
在 app 端，有 uniapp （本质也是 vue
在 pc 客户端，有 electron
好像真的什么场景都有 JS 的身影

@2i2Re2PLMaDnghL 感謝提點，後續我把那兩個思路也進行測試下；可能換 Oracle 會得到更好的效果，但投入也是巨大的。

@2i2Re2PLMaDnghL
Oracel 之前某个业务使用过，但就目前个人对 Oracle 各项优化方式和使用上并不熟悉，除非 Oracle 内部对查询器进行了优化，否则我觉得性能上估计相差不大，而且除去成本而言，用 Oracle 的话太多关联的程序需要改动，代价太大了；

之前也有业务上使用 Oracle，当时大概是因为 需要通过存储函数 触发 脚本运行 把数据提交去上级的 Oracle 中。

@2i2Re2PLMaDnghL

》且抛开这个
SELECT id FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
170W 左右的數據，耗時 1.3 秒；

SELECT * FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
170W 左右的數據，耗時 23 秒；

第 2 點測試過，效果基本沒變化；
第一點由於要加欄位，所以只能後續在測試環境中測試下

@wowbaby 业务形式不一样，我们的是酒店价格，所以价格是按日为单位，每天的都不一样，
酒店--product
房间--spu
销售计划--sku

常规商城的价格这个放去 sku 表中，
但酒店由于每天房型价格都不一样，所以还会多一个价格表，记录销售计划和销售日期 的售价；
比方说：
汉庭酒店
|--标准房
|----当天可售
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----提前 3 天预定
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----不可取消
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|--豪华房
|----当天可售
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----连住优惠
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......


实际业务情况是
可能哪天，整个房型都需要停售，这时候 spu 上的 isActive 就设置为 0 ；
可能哪天，某个房型的销售计划停售，这时候这个 sku 的 isActive 就设置为 0 ；
可能哪一天的房停售，这个时候 price 的 isActive 就会设置为 0 ；


一般情况下，当携带酒店 ID 和入住日期去查询信息，返回时间基本是毫秒级别；
仅仅是当需要显示列表形式的时候（只有入住日期没有酒店 ID ），查询时间十多秒。

@disk explain 看过了，属于正常，现在困惑的地方在于优化...
因为从 product->spu->sku->price 条件关联后数据几何倍增，就如您所说的 14 秒是正常.但总觉得有地方可以继续优化但被忽略了.


@cppc 现在查询都是在从库进行的，我之前也是想把 productID 做去 price 表中，但是因为还有 spu 和 sku 可售状态筛选的问题

@nonoyang
应该说 skuID 对应的产品 ID 永远不会变
但是 spu 表和 sku 表的 isActive 会经常改变，
这个时候除非把 spuIsActive 和 skuIsActive 还有 pid 增加到 tbl_price 这里；
但是引申出问题就是 spu 和 sku 的可售状态改变(isActive)，那 tbl_price 将进行大量更新.

@nonoyang skuID 对应的产品 ID 是唯一的；


@lenmore
@2i2Re2PLMaDnghL
@zoharSoul
因为实际情况还有以下几个环节，一开始漏了写上来：

```
tbl_product:
id：唯一主键
isAcitve：int(1)上架 /下架
...

tbl_spu:
id：主键
pid:int 对应 tbl_product.id
isActive:int(1)上架 /下架
...

tbl_sku:
id:主键
spuID:int 对应 tbl_spu.id
isActive:int(1)上架 /下架
...

tbl_price:
skuID：对应 tbl_sku.id
bookDate：日期
isActive:int(1)可售 /停售
price:int 价格
/*其中 skuID+bookDate 为联合主键*/

SQL:

SELECT
p.*,min(price) as price
from
tbl_product p LEFT JOIN
tbl_spu spu ON spu.pid = p.id LEFT JOIN
tbl_sku sku ON sku.spuID = spu.id LEFT JOIN
tbl_price price ON price.skuID = sku.id
WHERE
p.isActive = 1
AND spu.isActive = 1
AND sku.isActive = 1
AND price.isActive = 1
AND price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
AND price.price > 0
GROUP BY p.id
LIMIT 10


逻辑是查询 10 个可售产品；
可售定义是 product/sku/spu/price 的 isActive 均为 1 且 tbl_price 的 price 大于零 且 价格范围在 '2021-10-10 ~ 2021-10-17'
所以价格表无法冗余；

```



@chenzheyu
ORM 感觉只是方便了 SQL 语句的读写，对于性能而言不会有帮助吧；
left join 改为 where in 方式我还没试过，等等去试试，但估计结果差不多。

偷懒：
前端翻译，直接翻译成各国语言。

精准：
直接加字段 ，字段 x 语言数。

直观：
多库，搞好中文的，copy and paste 。

实际项目中，一般要求高的客户（翻译精准度），都是用方案 2 来解决，但他们都是中英形式。
大多数的客户，他们由于没有专业人员翻译，英简都是直接反代第三方翻译 API 缓存结果前端展示的形式。
简繁的话就直接系统转换，自己修正下。

钉钉没研究过，但微信就是跑 nodejs，开发者工具和企业微信一样。
我觉得没必要在乎它用什么写...
而你们前端提到的我觉得和是否 web 形式毫无关联...
在 web 中本来就没有限制字数的功能（ textarea ），
都是靠 JS 来实现的，
JS 绑定的触发不同，实现出来的逻辑表现就不同；
比方我绑定 onChange/input 时，输入的时候就会出现你提到的问题。
但是如果我绑定的是 blur，那就不会出现这个问题。

@iqoo
函数式 和 方法式 我觉得没必要要求统一...
当然仅仅是个人习惯而已，
针对前端 1 年以上经验的，哪种使用方法调用和哪种使用函数调用基本都了解了。
但是突如其来都变成函数式，他还要去追代码看......

我知道不能以我的个人习惯去否决其他人的个人习惯，
只能说对我而言意义不大，毕竟我只是个后端，前端太多东西让人眼花缭乱....