不能直接上线，必须人工验证。eversql仅基于静态sql分析和模式匹配生成索引建议，不感知数据分布、查询频率、写入压力、现有索引冲突、隐式类型转换、统计信息时效性及事务锁协同效应等关键因素。
EverSQL 推荐的索引真的能直接上线吗？
不能直接上线，必须人工验证。EverSQL 是基于静态 SQL 文本分析 + 模式匹配生成建议，不感知实际数据分布、查询频率、写入压力或现有索引冲突。
常见错误现象：EXPLAIN 显示走了它推荐的索引，但执行时间反而更长；或者推荐了 CREATE INDEX idx_a_b_c ON t(a,b,c)，而表上已有 idx_a_b，新索引冗余且拖慢 INSERT/UPDATE。
- 使用场景：适合快速扫描慢查询日志里的单条
SELECT，作为索引优化起点，不是生产决策依据 - 参数差异：它无法识别
WHERE a = ? AND b > ?中b的选择性——如果b列 95% 值是0，复合索引里b放第二位几乎无效 - 性能影响：它不评估索引大小、维护开销，对高写入表（如订单流水）盲目加联合索引可能让
INSERT变慢 20%+
为什么 ORDER BY + LIMIT 查询的推荐索引经常不准？
EverSQL 把 ORDER BY x DESC LIMIT 10 简单等价于“需要 x 上的索引”，但真实生效取决于是否能跳过排序——只有当 WHERE 条件能定位到连续数据块时，INDEX(x) 才真正高效。
典型反例：表有 1000 万行，WHERE status = 'active' 返回 800 万行，再按 created_at DESC 取前 10 条——这时 INDEX(created_at) 完全没用，必须是 INDEX(status, created_at) 才可能避免 filesort。
- 它不会检查
WHERE和ORDER BY字段是否存在逻辑关联（比如status和created_at是否有业务时间窗口约束） - 对
DESC支持有限：MySQL 8.0+ 才支持降序索引，老版本推荐INDEX(x DESC)会静默转成ASC，导致排序失效 - 示例：它给
SELECT * FROM logs WHERE app = 'api' ORDER BY ts DESC LIMIT 1推荐INDEX(ts)，但正确解法是INDEX(app, ts)
自动优化建议里出现 DROP INDEX 要特别小心
EverSQL 标记“冗余索引”时，只比对字段前缀是否完全覆盖，不验证查询模式是否依赖特定顺序或隐式类型转换。
常见坑：INDEX(a,b) 和 INDEX(a) 被判为冗余，但它忽略了 WHERE a = ? ORDER BY b 场景下 INDEX(a) 无法避免排序，而 INDEX(a,b) 可以——删掉后者会让原本 5ms 的查询变成 120ms。
- 它不捕获隐式转换：如果
a是VARCHAR但查询里传了数字WHERE a = 123，MySQL 会放弃索引；此时INDEX(a)实际无效，但 EverSQL 不知道 - 不考虑统计信息时效性：
ANALYZE TABLE没跑过，它的“选择性估算”完全失真 - 路径风险：它生成的
DROP INDEX语句没有IF EXISTS，在多环境部署时可能因索引名不一致直接报错
和 pt-index-usage 或 performance_schema 对比差在哪？
EverSQL 是“纸上谈兵”，后两者是“看实际流量”。前者分析你提交的 SQL 样本，后者统计真实执行中哪些索引被用、用了多少次、有没有回表。
一个具体差距：EverSQL 看到 SELECT id,name FROM user WHERE email = ? 就推荐 INDEX(email)；但 performance_schema.table_io_waits_summary_by_index_usage 可能显示该索引过去 7 天零命中——说明应用早改走缓存或其它路径了。
-
pt-index-usage需解析慢日志，能发现“理论上该走索引但实际没走”的 case（比如因隐式转换失效） - EverSQL 无法识别索引合并（index merge），看到
WHERE a = ? OR b = ?可能乱推两个单列索引，而 MySQL 5.6+ 实际用 index_merge 更快 - 兼容性盲区：它对 TiDB、PostgreSQL 的索引规则套用 MySQL 模型，推荐的
INCLUDE列在 MySQL 5.7 下根本不可用
最易被忽略的一点：它所有建议都假设查询是孤立执行的。现实中，一条 SELECT 可能和上游事务锁住的行冲突，这时候加索引不仅不加速，还可能扩大锁范围——这种协同效应，算法看不到。
