记录自己踩过的每一个坑

• 问题：把 Like "%" 放到应用环境中的后果。

CREATE TABLE aa (
   id int(11) UNSIGNED NOT NULL COMMENT 'PK',
   aa varchar(50) NOT NULL,
   bb varchar(255) NOT NULL,
   c char(128) NOT NULL COMMENT 'details',
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 ALTER TABLE chn_user_v3
   ADD PRIMARY KEY (id),
   ADD UNIQUE KEY aa + bb (aa,bb);

在最早设计时，忽略了一些问题。建表时，唯一索引是一个联合索引，但索引第一列里的值需求是模糊查询。写代码时，用了 aa like "xx%xx" AND bb = "xxxx"。在测试阶段，因为数据量少，访问量低，并没有发现问题。直到数据到了 3M，QPS20左右时，问题爆发了。
执行sql，大概要1秒。导致很快 mysql 的1000个连接每耗尽 -> 大量的too many connections的报错。
解决问题：
a. 代码取消了 aa like "xx%xx"。但bb列没有索引，并没有提升。
b. 代码中改成了 aa like "xx%"。这样可以命中索引，效率得到一点点提升，但还是很慢。并没有解决所有问题。
c. 在没有其它办法的情况下，运维同学给 bb 建了单独的索引。然后在脚本中，只按 bb = "xx" 查找。然后用代码区分 aa 。
PS：这里其实也有问题，因为是线上环境，在执行 CREATE INDEX bb ON aa (bb) USING BTREE; 可能会锁表。运维的同学费了些劲才建好。
反思：
a. 在建表的时候，一定要想清楚，问清楚。
I. 联合索引，一般要把固定的部分放在前面
II. 可能需要拆开的字段，尽早拆开
III. 不要相信任合人，给你说，"不用管性能，只要能跑通"，这类话。因为遇到问题的时候，只能你自己能解决。

• 问题 0 == "x" 在php中的应用

在PHP里，在使用"=="判断时，总是把后面的类型转成和前面一样再判断。
也就是如果前面是数字 0，后面时字符时，会先把字符转成整数型，再判断。intval("x") 是0。所以这个等式会返回 true。

• Intval 的取值范围

某个平台的订单号，发现在通过我们的脚本处理过之后，全部变成了一样的。看到订单号之后，发觉是超过了php，intval函数处理的最大范围。

32位： -2147483648 ~ 2147483647
64位：- 9223372036854775808 ~ 9223372036854775807
参考： https://www.php.net/manual/zh/function.intval.php

• 空格“ ”，加号+。在 http 请求中.......

建议用 http_build_query() 来处理参数。否则，这2个符号真的能把你搞疯掉....。