唯一ID字段的合适索引类型及慢查询问题排查

核心问题：用错了索引类型 #

你给uuid字段加的FULLTEXT（全文）索引，完全不适合当前的查询场景。FULLTEXT索引是针对文本内容的关键词搜索设计的，根本无法高效支撑WHERE uuid='xxx'这种精确等值匹配。对于单值精确查询，必须使用MySQL默认的BTREE普通索引。

修复步骤： #

1. 给uuid字段添加正确的BTREE索引：

   ALTER TABLE Transactions ADD INDEX idx_uuid (uuid);
   

2. 删除无用的FULLTEXT索引（先通过SHOW INDEX FROM Transactions;找到全文索引名称，再执行删除）：

   ALTER TABLE Transactions DROP INDEX 你的全文索引名;
   

换成正确索引后，17000条数据的查询应该能降到毫秒级，不会再出现数秒延迟。

VARCHAR(29)的影响 #

改成VARCHAR(29)有一定意义，但不是解决慢查询的核心：

• MySQL的VARCHAR会存储实际字符串长度，所以VARCHAR(60)存29位的UUID，实际占用空间和VARCHAR(29)几乎一致，性能差异可以忽略。
• 改成VARCHAR(29)能明确字段的合法长度，避免存入不符合格式的数据，属于规范层面的优化，对查询性能提升极小。

内存问题的可能性 #

1GB内存的MySQL实例对于17000条、209MB的表来说，正常情况下完全足够。除非你的MySQL配置不合理，比如innodb_buffer_pool_size设置得太小，导致频繁磁盘IO。

如果换完索引后仍有性能问题，可以检查缓冲池配置：

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

对于1GB内存的机器，建议把innodb_buffer_pool_size调整到512MB左右（不要超过内存的70%），让更多数据缓存到内存中，减少磁盘访问。

内容的提问来源于stack exchange，提问作者Mihail Minkov