#36 @x2ve
> 特别感谢：Vicer 、cxt 、hiCasper 等各位技术大佬的脚本，站长只是脚本的"搬运工"。
> 版权申明：以上所有脚本、系统均为网络收集，站长不对资源的安全及版权纠纷负责，如有侵犯您的权益欢迎联系。
https://i.imgur.com/ppUCuAl.png
那您又如何保证他提供的这些系统镜像就是安全的呢？为什么不亲自去官网下镜像手动安装？

#32 @hello2090 从密码学理论上讲很难将随时都需要加 /解密的数据（硬盘就是典型的同时有 IO 而不是只读）托管给他人却不提供给他任何密钥（不论对称还是非对称）
除非您的数据只读或只写，那就可以利用非对称加密而只提供给他公钥从而保证他只能解密信息不能加密（或只能加密而不能解密）
建议复习密码学基础与 TLS GPG PGP 等流行实践

如果您真想阻止服务商乱扫文件除了简单的卸掉他们在预装的系统镜像中内置的监视程序外还可以使用对硬盘数据进行 AES 对称加密一类的服务，我记得阿里云 aws azure 都有提供（阿里云的好像收费），可以使用他们提供的密钥或您自己上传密钥（当然 AES 不是非对称加密所以同时用于加 /解密的密钥最终还是得在他们手里，但这总比裸奔还用着默认镜像里自带的“安全”监视程序要好些）
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
https://help.aliyun.com/document_detail/59643.html

#30 @hello2090 这是两码事，我只是描述了最初把 iaas 称作公有云（资源）的商业人士为什么要这样叫，因为他们认为基础设施是公有公用共产的

#26 @hello2090 对于兜售名词新概念的商业营销人员而言是指云服务 as 公共资源，就像 infrastructure 这词本身，水电气通信这种基础设施是公共资源，而他们希望以 IaaS 为代表的计算服务也能像水电一样变成人类的必需品（人人都要买 xx 云）

#4 早已道明`你为何不看一眼生成的 SQL ，不就知道区别在哪里了？`

#1
INSERT INTO `user`(field, name, email) VALUES(null, 'Jack', '@email.com')
INSERT INTO `user`(name, email) VALUES('Jack', '@email.com')

说白了就是 null 值的语义到底是 作为字段列表的 null 值 还是 不在字段列表中指定他
而数据库层对您没指定的字段赋值是 field default value ，如果没有 field value 会返回 ERROR

> 像这篇文章（ https://www.codenong.com/13466954/）

有没有可能，这是又一个 stackexchange 机翻垃圾站：
https://stackoverflow.com/questions/13466954/how-to-store-a-java-object-with-variable-number-of-attributes

#4 @James0 换不换别的数据库主要看他愿不愿意，毕竟有学习迁移成本，比如得扔掉 sql 重新学习 mongo query lang （当然如果他本就不会手写 sql 一直都是靠 orm 抽象隔离那也没多少区别）

GIS 场景的 GeoTIFF ？ https://en.wikipedia.org/wiki/GeoTIFF https://www.geospatialworld.net/article/geotiff-a-standard-image-file-format-for-gis-applications/

https://postgis.net/docs/using_raster_dataman.html
https://gdal.org/drivers/vector/pg.html
https://docs.qgis.org/3.22/en/docs/user_manual/managing_data_source/supported_data.html

> An error occurred

什么 error 呢？您能否找出更具体的错误信息？
mysqld 负荷压力大不大？是不是一大堆 sql 卡着一直在执行？看看 SHOW PROCESSLIST
看看 SHOW ENGINE INNODB STATUS\G ？还有 mysql 本身的 errorlog

wa=waiting for i/o ，又称 iowait
wa%的统计口径是一切 hardware interrupt 造成的 cputime ，他本身被归类到 idle%中

https://serverfault.com/questions/12679/can-anyone-explain-precisely-what-iowait-is 进一步指出
> IOWait （通常标注%wa 在 top ）是 idle 的一个子类（%idle 通常表示为除了定义的子类之外的所有 idle ），意思是 CPU 没有做任何事情。因此，只要 CPU 可以处理另一个进程，它就会处理。此外，idle 、user 、system 、iowait 等都是针对 CPU 的度量。换句话说，你可以把 iowait 看作是等待 io 导致的空闲。
> 准确地说，iowait 是接收和处理硬件中断所花费的时间占处理器滴答的百分比。软件中断通常单独标记为%si.
> 但是没有 iowait 并不一定意味着您的应用程序在 IO 上没有瓶颈。考虑在一个系统上运行的两个应用程序。如果程序 1 是严重的 io 瓶颈，而程序 2 是重度 CPU 用户，则%user + %systemCPU 可能仍约为 ~100%，相应地，iowait 将显示 0 。但这只是因为程序 2 是密集型的，相对而言似乎什么也没说程序 1 ，因为所有这些都是从 CPU 的角度来看的。

> 假设有两个程序在一个 CPU 上运行。一个是从磁盘读取的“dd”程序。另一个是不执行 I/O 但将 100% 的时间用于计算工作的程序。现在假设 I/O 子系统有问题，并且物理 I/O 需要一秒钟才能完成。每当“dd”程序在等待其 I/O 完成时处于休眠状态，另一个程序就可以在该 CPU 上运行。当时钟中断发生时，总会有程序运行在用户态或系统态。因此，%idle 和 %iowait 的值将为 0 。即使 iowait 现在为 0 ，这并不意味着没有 I/O 问题，因为如果物理 I/O 需要一秒钟才能完成，则显然存在问题。

https://serverfault.com/questions/684339/why-cpu-spent-time-on-iowa
> CPU 空闲状态分为两种不同的“子”状态：iowait 和 idle 。
> 如果 CPU 空闲，则内核然后确定是否有至少一个当前正在进行的 I/O 到本地磁盘或从该 CPU 启动的远程安装磁盘 (NFS)。如果存在，则 CPU 处于状态 iowait 。如果没有从该 CPU 启动的正在进行的 I/O ，则 CPU 处于 idle 状态。
> 因此，iowait 是 CPU 空闲时间的百分比，并且至少有一个 I/O 正在从该 CPU 启动。
> iowait 计数器表明系统可以处理更多的计算工作。仅仅因为 CPU 处于 iowait 状态并不意味着它不能在该 CPU 上运行其他线程或进程。
> 所以，iowait 这只是一种空闲时间。

（假设是 Linux ，虽然一般概念可以应用于其他操作系统。）

https://serverfault.com/questions/972343/what-is-the-relation-between-io-wait-utilisation-and-load-average
> 工作负载不能仅通过平均负载和 %iowait 来描述。这些指标仅汇总特定状态下的任务。分别计算可运行和不可中断、空闲时间和未完成的 I/O 。
> 您可能会遇到这样一种情况，即有任务处于可运行状态，有一些空闲 CPU 周期，但 I/O 上没有空闲。想象一个有点繁忙的 Web 服务器，有 200 个工作进程在 2 个 CPU 上运行。平均负载约为 1 ，iowait 接近 0 。任务很多，每个任务的工作量都不是很多，CPU 闲置但在磁盘上等待的时间更少。

如果这个假设的 Web 服务器 VM 被实时迁移，它的内存延迟和可用的 CPU 时间可能会受到短暂的影响。一个症状是更高的平均负载，但这不会驱动 iowait 。

typo：EVA=>EAV

wp 中 postmeta 的用途：
https://codex.wordpress.org/Post_Meta_Data_Section
https://developer.wordpress.org/reference/functions/get_post_meta/

https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
典型例子是 wordpress 中臭名昭著的 wp_postmeta 表 https://codex.wordpress.org/Database_Description

但 EVA 性能也不如文档数据库（如 mongo ）好，除非按 meta_key 分 partition 甚至分表

回顾经典之
i.imgur.com/rBPck8C.png

/t/908231
/t/909074

> 重启 MariaDB 之后

每次 mysqld 重启都会完全清空内存中的 innodb buffer pool ，而您再次在重启后的 mysqld 上首次查询这 sql 就需要从硬盘读大量 innodb page 进 buffer pool ，所以这时吃内存和硬盘 io 拖慢了 sql 耗时

> 重启之后对那条带 IN 的语句改来改去一阵之后又 10 毫秒左右

实际上您啥也不改单纯的在等到这查询所需的 page 都进了 buffer pool 之后再怎么反复执行耗时都是差不多的（除非您的 buffer pool 太小或是其他无关 sql 又进来导致 page 被反复逐出 pool 又从硬盘读取进 pool ）

> 我发现的异常。刚插入随机的测试数据之后 explain 那条带 IN 的语句 key 是 tag_content_rel_index ，key_len 是 4 ，rows 是一万左右。重启之后 key 是 content_index 。强制用 tag_content_rel_index 之后 key_len 是 8 ，rows 是 1

因为您创建表并狂暴轰入大量垃圾数据后没 ANALYZE TABLE 和 /或 OPTIMIZE TABLE 所以查询计划优化器还以为这表里头没有几行所以就选择了可能更慢的计划 stackoverflow.com/questions/586381/mysql-not-using-indexes-with-where-in-clause
还要看 filtered 是多少

> 另外 10 毫秒左右的是不是就没法优化了？

一条 sql 耗时 10ms 还需要优化？
如果这 sql 返回的行很多那实际上查询结果从 mysqld 到您的业务程序的 dbdriver ，再从 dbdriver 进入您的业务代码被您写的奇妙深刻业务逻辑消费的时间都远超 10ms 了（如果 mysqld 跟您的业务程序不在同一 localhost 而是走网络那延迟更高，那些选择无脑上云的业务环境里就是这样）
还不论从您的业务程序最终输出 html/json/xml 后走网络到最终用户那又要多久

> 在我的电脑上那条带 IN 的语句的执行时间很不稳定，有时候 10 毫秒左右，有时候一两秒，有时候一二十秒。这么不稳定的执行时间我接受不了了。之前说不纠结这个一部分就是因为很多次都是 10 毫秒左右，现在这么不稳定不能不纠结了。我新问了一个问题： https://www.v2ex.com/t/909074 。忙的话就不用看了。

您后台是不是跑着一堆频繁内存 /硬盘 io 的程序？您应该先把他们都关掉以控制变量，或是直接去开个空白服务器专门测试这些
您 innodbbufferpoolsize 多少？是不是还用着默认的 128M ？

> https://blog.csdn.net/kevinxxw/article/details/109567275
> in 通常是走索引的，当 in 后面的数据在数据表中超过 30%（上面的例子的匹配数据大约 6000/16000 = 37.5%）的匹配时，会走全表扫描，即不走索引，因此 in 走不走索引和后面的数据有关系。

这不就是 cost-based optimizer 认为直接 full table scan 的 IO 时间开销比去使用索引然后反复在 primary/secondary index 和具体的 datanode 之间绕圈子更快？这跟 where in 有关系吗？
您自己建个只有 10 行的表，哪怕您给`WHERE field=1`的 field 加了索引 EXPLAIN 也会显示根本不使用您加的索引因为 scan10 行远比去索引里绕要快
so 人早已道明真相： https://stackoverflow.com/questions/586381/mysql-not-using-indexes-with-where-in-clause

另外阁下看着这些简中互联网的 csdn 垃圾还不如去啃 en 文档或 en 书籍：
https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html
https://use-the-index-luke.com/sql/where-clause/searching-for-ranges/greater-less-between-tuning-sql-access-filter-predicates


> 估计属于可得性偏差了。大意是认为容易想到的东西出现的概率更大。我平时经常用知乎，stackoverflow 好像是没用过，虽然经常能搜到上面的问题。因为经常用知乎，所以以为知乎的那套规矩是比较常见的。其实我之前也想过那可能只是为了赚钱和增长之类的原因才那么定的，不过应该是可得性偏差的力量太强大了。

逼乎那群功利主义者带 v KOL 您指望什么？整天吹嘘着知识付费然后反手把几年前发的回答给删了放进盐选订阅里
等您花了几块钱巨款打开一看全都是车轱辘话和十几年前 web2.0 时代的互联网上唾手可得的信息的复制粘贴嗯缝合，或是像 csdn 人那样去机翻 en 互联网上的公开免费信息回来兜售二手屎
stackexchange 人至少不搞什么乱七八糟的 monetize ，您把您的 sql pastebin 发到 dba.stackexchange 上同样会有人指出您的`WHERE tag_id`无法直接使用索引而只能`using index for skip scan`，所以应该按照最左字段原则改变 composite key 中的字段顺序

> 你的意思是你很忙吗？是的话那抱歉消耗你时间了。

我只是说我们都在与 mysql 搏斗

REPAIR TABLE 是用于以前使用 myisam 引擎的表的，您的 sStatus 的 table engine 是 innodb 还是 myisam ？（还有人用 myisam ？）

与此同时：我还在与表结构 migration 搏斗
https://i.imgur.com/dWpNcH2.png