https://i.imgur.com/kNIQHtg.png
OPTIMIZE 个 TABLE 先
https://i.imgur.com/Q6E5tBI.png

https://i.imgur.com/r2g8FPc.png
所以阁下想优化`SELECT * FROM tag_content_rel WHERE content_id = 50000`？还是什么？

```
tbm> CALL add_tag(1000)
[2023-01-13 19:51:43] 100 rows affected in 842 ms
tbm> CALL add_content(1000)
[2023-01-13 19:51:44] 100 rows affected in 875 ms
tbm> CALL add_tag_content_rel(100000, 100000, 100000)
[2023-01-13 19:54:15] 100 rows affected in 2 m 30 s 141 ms
tbm> USE tag_test
[2023-01-13 19:54:17] completed in 356 ms
tag_test> SELECT *
FROM tag_content_rel
WHERE content_id = 50000
[2023-01-13 19:54:25] 85 rows retrieved starting from 1 in 6 s 972 ms (execution: 6 s 700 ms, fetching: 272 ms)
tag_test> USE tag_test
[2023-01-13 19:54:26] completed in 572 ms
tag_test> SELECT content_id, COUNT(*)
FROM tag_content_rel
WHERE tag_id IN (730,2621,2805,3200,3340,3590,3969,4039,4799,5249,8859,11894,12628,12646,16959,17024,17142,18032,18861,19316,20839,21179,22346,22507,22522,22639,23562,23822,25172,25786,25821,26606,29899,29917,30586,30901,31216,31413,32562,32567,34740,36586,36954,38109,39202,40519,40756,40816,41464,42942,43069,43286,43344,44787,44950,45549,45652,46313,47111,50549,51942,52738,52959,52961,54034,55526,59162,59767,59945,60361,60816,61307,61730,62269,62503,62589,63960,64580,64634,64794,65209,66332,68222,69396,69905,70629,70939,71277,71804,72580,72896,73651,74301,74525,74706,75153,76169,76500,78042,78148,79109,81463,82140,84217,85212,85327,85584,86392,86908,88188,88475,89175,89190,91156,93202,94124,95294,95345,96013,98135,99679)
GROUP BY content_id
ORDER BY COUNT(*) DESC
[2023-01-13 19:54:28] 500 rows retrieved starting from 1 in 555 ms (execution: 402 ms, fetching: 153 ms)
```

> 让你回复了这么多很不好意思。你回这么多图的是什么？这些明显属于个人咨询了，你回的这些东西好像很难帮到除了我以外的人吧？

那阁下来 v2 问您的特定于您的表结构场景的问题又什么什么目的？

> 之前问朋友朋友说如果达到千万级别就不用我优化了

经典提前优化与钞能力

恭喜阁下已经入门了 FP （函数式编程）思维

可能原因： https://github.com/phpmyadmin/phpmyadmin/issues/17527

我之前也被 pma 白屏折磨过

不要用 phpmyadmin 的"最新"（ 5 月 12 ）构建 5.2.0 版本
而是下追随 latest git commit 的 5.3+snapshot 构建

pma 的 5.x 版本是大的重构，他们试图进行把前端慢慢 spa 化
所以 5.x bug 特别多

但这不适用于您遇到的
> 似乎一级目录 vger.kernel.org/没有链接或者列出二级目录
> 但维护网站的人最好能提供链接吧？这个网站有好多有用的 pdf 和 ppt

wget -r 不过就是像爬虫那样去跟踪下载到的 html 中所有 url 并递归下载下来

win 上也有个类似 wget -r 的商业软件 https://metaproducts.com/products/offline-explorer
我以前用过破解版 archive 过几个小网站

wget --recursive
https://www.gnu.org/software/wget/manual/html_node/Recursive-Retrieval-Options.html
https://stackoverflow.com/questions/273743/using-wget-to-recursively-fetch-a-directory-with-arbitrary-files-in-it

所以拥有 aes 解密密钥的 shc 程序并不位于`不信任的环境`之中？
shc 只是负责解密变回合法 bash 字符串后把 bash 字符串传给`不信任的环境`来 eval ？

您需要控制{}的插值也就是那个 id 变量的取值区间，如果他来自程序内部那还比较容易保证其合法（比如您 1 楼所说的`query.order 是请求接口传过来的值，是一个枚举类型`），如果是用户输入您必须得假定恶意对它做合适的过滤甚至白名单

#15 @h0099 所说的 `给 query builder 传入 raw 部分如 selectRaw(用户输入)`实际上就是
#21 的`同时混用 字符串拼接 和 prepared statement 的传参插值`
您可能会觉得我从来都没有做过 在 prepared statement 里又直接拼接了用户输入 的罪恶行径
但实际上 orm 的 query builder 通过抽象隔离使得您在使用其提供的 selectRaw()等 api 时也忘记了这实际上就是危险的拼接

@GreatAuk 他的意思是前后端分离做好后前端就只是一大堆静态资源 htmljscss ，所以这些静态文件随便托管在哪儿都可以只要用户能在访问域名时下载到这些文件
那么前端静态资源的并发就是看您托管的地方的并发了，而这基本是不用担心的
因为 oss 和 cdn 服务端所做的不过是去缓存（当然可能 cache miss ）里读取一些文件响应而已，也就是 nginx 等 webserver 最擅长的事

win8.1 50~60 个
https://i.imgur.com/j0kt669.png
https://i.imgur.com/pQyBsta.png

回顾上个月的新闻： 微软希望通过将功能与 explorer.exe 解耦来提高 Windows 11 的运行速度
https://www.windowslatest.com/2022/12/22/microsoft-wants-to-make-windows-11-faster-by-decoupling-features-from-explorer-exe/

#19 @IvanLi127 phpdelusions.net/pdo/sql_injection_example 所举的例子就是典型的同时混用 字符串拼接 和 prepared statement 的传参插值以实现将用户输入用于无法作为 prepared statement 的传参插值的地方（原文例子中是用于 UPDATE ... SET 子句，现实中更常见的就是 SELECT ...子句的字段名，或是楼上 ORDER BY ...子句的字段名），所以字符串拼接是这的短板

#20 @IvanLi127 byte0x39=字符串 9 是 ASCII 里的，不论什么 EASCII 编码都不可能修改掉这个 0x39 对应 9 的关系（顶多像 SHIFT-JIS 那样把\改成￥），那么您所说的转了几手难道是传输给使用远古的 BCDIC 编码的环境里了吗？还是阁下直接在前端验证用户输入白名单，所以无法保证后端收到的就是 0x39 byte ？

@sorcerer 单纯的没有，但只要遇到有意无意的把用户输入直接拼接进字符串那就需要对用户输入做严格的过滤（如正则）甚至白名单（如只允许已知字段名）

@opengps nginx 当然可以设置非 localhost 的其他局域网甚至公网 ip upstream server
http://nginx.org/en/docs/http/ngx_http_upstream_module.html
http://nginx.org/en/docs/http/ngx_http_proxy_module.html
因此 nginx 也可以跑在一个独立机器系统上，而前后端跟 nginx 可以有也可以没有物理上的关系（只要能通过网络访问就行）
那些 load balancer 不就是这种模式

/dev/random 无疑是密码学的更好选择。即使 /dev/urandom 相对安全，也没有理由选择后者。

事实： /dev/random 有一个非常讨厌的问题：它会阻塞。

但这很好！/dev/random 给出的随机性与其池中的熵一样多。/dev/urandom 会给你不安全的随机数，即使它早已耗尽熵。

事实：不。即使不考虑可用性和随后的用户操纵等问题，熵“耗尽”的问题也是一个稻草人。大约 256 位的熵足以在很长很长一段时间内获得计算上安全的数字。