前言
最近刚好学完数据库MySQL，今天看到一篇文章：“美团二面：现在有一张千万级数据量的订单表，要给几个常用查询条件字段建索引，需要注意什么？”，我想，这不就是我最近学的MySQL里面建立索引规则的东西嘛。其实本质问的就是怎么建索引使得查询效率高，而且容易维护等，问题只不过给个场景包装一下罢了。
千万级大表和普通表的区别
在千万级大表上建索引，有三个最直观的风险：
- 锁表时间超长：InnoDB在MySQL 5.6+ 支持Online DDL（大多数操作不锁全表），但仍有短暂的独占元数据锁，且创建过程会消耗大量IO和CPU，拖垮业务。
- 磁盘空间井喷：每加一个索引，相当于重建一张“影子表”，千万级数据可能占用几十GB临时空间，导致磁盘打满。
- 写入性能骤降：每个新索引都会拖累
INSERT、UPDATE、DELETE的速度。在大表上，这点尤其致命。
六要素
高选择性
选择性越高，索引的价值越大，也即是COUNT(DISTINCT column) / COUNT(*)接近1（这一列几乎没有重复值，唯一值占比极高）
比如说，用户ID，订单号等都是很好的选择；性别，订单状态（status）等就很不友好了，千万级大表的这些字段（列）会有大量重复数据，建索引的话，还是需要扫描大量数据，还不如全表查询快，因此不要将这类字段作为单独索引
正确的做法是建立联合索引，高选择性的在前，低选择性的在后
最左前缀原则
向上面的那样，建立联合索引后，应严格按照最左前缀原则工作
注意：范围查询要放在联合索引最后面
覆盖索引
覆盖索引是指索引中已经包含了查询需要的所有字段，不需要再回表查聚簇索引，极大减少随机IO。
避免多余和冗余索引
重复索引：完全相同列组合的多个索引。
冗余索引：一个索引是另一个索引的前缀。例如有了(a,b)，又建(a)就是冗余。冗余索引会浪费空间，建议删除一个
锁要短
用工具在线建索引，传统的ALTER TABLE在大表上可能会长时间阻塞写入（虽然Online DDL支持，但仍有短暂锁风险，且消耗资源）。
推荐工具：pt-online-schema-change (Percona Toolkit) 或 gh-ost，它们通过创建影子表、触发器，实现几乎零锁表的索引变更。
原理：复制原表，然后在新表建索引，最后重命名在替换就好了，实现几乎零锁表的索引变更
优点：不阻塞业务读写，可以限流控制负载。 缺点：需要额外的磁盘空间，执行时间长（千万级可能需要几小时）。
生产强烈建议：永远不要在高峰期对大表直接ALTER，用专业工具或维护窗口。
监控
定期分析索引使用情况，大表索引不是建完就万事大吉，随着业务变化，有些索引可能变成“僵尸索引”，只消耗资源从不使用。
大表建索引大致流程
- 先评估必要性：是否真的需要？能否通过分区、归档冷数据减少表大小？
- 列选择：只在高选择性、高频查询的列上建索引，避免低选择性列单独索引。
- 联合索引顺序：等值查询在前，范围查询在后；遵循最左前缀。
- 覆盖索引：尽量让索引包含查询所需字段，避免回表。
- 去冗余：用
sys.schema_redundant_indexes检查并清理无用索引。 - 安全变更：用
pt-online-schema-change或gh-ost控制锁，避免业务抖动。 - 持续监控：观察索引使用频率、碎片率，及时优化。
优缺点及适用场景
优点
- 大幅提升查询速度（尤其是高选择性列）
- 覆盖索引可避免回表，减少IO
- 合理设计能让千万级表的复杂查询从分钟级降到毫秒级
缺点
- 占用额外磁盘空间（一般占数据量的30%～100%）
- 降低写入（INSERT/UPDATE/DELETE）性能
- 管理复杂度高，DDL操作风险大
适用场景
- 只读或读多写少的业务（如订单历史查询、报表）
- 查询条件稳定，有明确的高频过滤字段
- 核心高频查询可以使用覆盖索引
不适用场景
- 写入极频繁的日志表（如埋点数据）——宁可降低索引量
- 数据量极小（<10万行）——全表扫描也很快
- 绝大多数查询不走索引（例如没有where条件）
总结
这就是大表建索引需要注意的点，总的来说，建的好，性能越好；建的不好，那就是磁盘爆满，写入崩溃。
