MySQL 面试题很容易被答成零散知识点：B+ 树、最左前缀、覆盖索引、事务隔离、MVCC。单点知识当然要会，但真实后端项目里，数据库问题往往是一个业务路径：读接口为什么慢，写接口如何保证状态正确，缓存和异步又会不会改变一致性。
如果能把索引和事务放到同一条业务链路里讲，答案会比单纯背概念更有层次。
慢查询先问查询形态
看到慢查询，不要直接说“加索引”。先看查询条件、排序、分页、返回列和数据分布。一个索引是否有效，不只取决于有没有建，还取决于查询能不能用上、区分度如何、是否需要回表、排序是否额外 filesort。
比如一个订单列表按用户、状态、时间筛选并按时间倒序，索引设计就要围绕这个访问路径。只给 status 建索引可能没用，因为状态值区分度很低；只给 created_at 建索引也可能无法同时满足用户筛选。更合理的是结合高频查询条件设计联合索引，并控制返回字段，让覆盖索引在合适场景发挥作用。
Explain 不是仪式，要能读出风险
面试里说会用 Explain 还不够，要讲能看什么。type 是否过差，rows 是否过大，key 是否命中预期索引，Extra 里是否有 Using filesort、Using temporary，都是排查线索。
但也不要把 Explain 当成唯一答案。线上慢还可能来自锁等待、连接池耗尽、返回数据太多、网络传输慢、ORM 生成了不合适 SQL。数据库排查要和接口耗时、慢日志、连接池指标一起看。
写路径靠事务和状态机兜底
读优化靠索引，写一致性靠的是事务边界、唯一约束、状态机和幂等。比如订单从待支付到已支付，不只是 update 一个字段。你要考虑重复回调、并发更新、支付渠道未知状态、消息补偿和后续通知。
一个稳的写入设计通常会把状态流转限制在合法路径上，用条件更新避免并发覆盖，用唯一键防止重复流水，用事务保证本地关键状态和记录一起提交。涉及外部系统时，还要接受“本地事务管不了外部动作”的事实，通过查询和补偿收敛结果。
索引也有代价
面试官如果追问“索引是不是越多越好”，答案一定是否定的。索引会占空间，也会增加写入维护成本。高频读路径值得建索引，低频后台查询不一定要为它牺牲核心写入性能。联合索引顺序也要根据查询形态和区分度设计，不能只按字段出现顺序拼起来。
这里可以补一个业务判断：核心接口的查询路径要稳定，管理后台的复杂筛选可以接受更慢，必要时走离线报表或搜索系统。数据库设计不是追求所有查询都快，而是让最重要的路径稳定可控。
更完整的面试表达
可以这样回答数据库项目问题：我会把读路径和写路径分开看。读路径先分析查询形态、数据量、排序分页和返回列，再用慢日志和 Explain 验证索引是否命中。写路径关注事务边界、状态机、唯一约束和幂等，涉及外部系统时用补偿和对账收敛。这样讲，数据库题就从背索引升级成了后端业务一致性设计。