继上次索引优化之后，线上出现一个问题，char11 in char10，因为空格不一致，不加trim所以不可能in到数据？
但是实际上会忽略空格吗？
（cust的cno为11，brrd的cust字段为10）
提前结论：
暂时先不改，因为这里是数据库执行，不确定应用层执行还是否能查出？
另外需求：trim存在导致索引失效（SQL特性，不管什么数据库）
实践：
将msd这里的trim去掉，结果发现还是185条？难道真的可以忽略，实际不是
条数是一致，但是这里是left join，所以条数不变是正常的，改成inner join
发现一条数据没有，说明关联不上，确实是以前的猜想
借鉴：ORACLE中关于 char 和 varchar2 的比较 - 黄景新 - 博客园 (cnblogs.com)
总结几个点：
不管是where字符还是表关联，char和char即使长度不相同，也总能匹配上，不管是工具还是应用层面
而对于varchar和char，一定是关联不上的，所以char必须去空格或varchar加空格
（这个结论是对的，你想不明白是因为没区分好其他的join等关系（比如left join当然不起条数的筛选作用），所以可能导致查处count一样，实际上是匹配不到的）
:::success
而对于数据库为varchar，但是where串为char，在应用层有可能查不到，这种不一样的在前面多数据库中有总结，因为工具和应用层不一样
:::
MySQL索引重建
我们知道可以使用 OPTIMIZE TABLE 命令，但是其原理是什么？
首先我们先明确数据库（表）在使用中产生的问题：
- **索引：**索引是创建index的时候生成的索引B+树，所以经过使用之后，比如删除等操作， 表的索引变得分散或不连续，查询性能下降。
- 数据碎片化：在频繁进行插入、删除和更新操作后，表数据可能会变得碎片化，导致性能下降。
- 空间回收：删除大量数据后，物理磁盘空间并不会立即回收，
<font style="color:rgb(199, 37, 78);background-color:rgb(249, 242, 244);">OPTIMIZE TABLE</font>可以帮助回收这部分空间。
原理：
对于 InnoDB 表，<font style="color:rgb(199, 37, 78);background-color:rgb(249, 242, 244);">OPTIMIZE TABLE</font> 实际上会执行 <font style="color:rgb(199, 37, 78);background-color:rgb(249, 242, 244);">ALTER TABLE ... ENGINE=InnoDB</font> 来重建表。这个过程会创建一个表的副本，然后将原表的数据复制到新表中，最后切换到新表并删除旧表。
ps：在 OPTIMIZE TABLE 执行期间，表会被锁定，对该表的读写操作将会被阻塞，直到操作完成。
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！