数据库用久了，查询变慢是常有的事。为了加快检索速度，很多人会想到加索引。但你有没有遇到过这种情况：刚给一张大表加上索引，系统反而卡了？页面加载不动，后台任务排队，这时候就会有人问：创建索引到底会不会影响性能？
加索引不是“无痛升级”
很多人以为索引就像书后面的目录，加上就能查得快，还不占地方。但实际上，创建索引的过程本身是要消耗资源的。尤其是对数据量大的表，数据库需要扫描整张表，把数据按索引规则排序、写入新结构，这个过程会占用大量CPU、内存和磁盘I/O。
比如你有一张用户登录日志表，几千万条记录。在白天高峰期执行 CREATE INDEX 命令，很可能导致其他查询被阻塞。MySQL 在创建普通索引时虽然支持并发读（从5.6开始有优化），但写操作还是会受影响。而唯一索引或主键索引的创建，更可能引发全表锁。
线上操作得挑时间
曾经有个运维同事在上午十点给订单表加索引，结果APP下单接口大面积超时。监控一看，数据库IO直接拉满。后来改到凌晨两点操作，配合低峰期流量调度，才顺利完成。这说明：不是不能加索引，而是时机很重要。
现在主流数据库都提供在线DDL功能。比如MySQL 8.0的 ALGORITHM=INPLACE 和 LOCK=NONE 参数，能让创建索引过程中表依然可写：
CREATE INDEX idx_user_email ON users(email) ALGORITHM=INPLACE, LOCK=NONE;但这也不是万能的。如果服务器配置低，或者表特别大，即使不锁表，执行时间也可能长达数小时，持续占用系统资源。
索引多了也会拖累写入
别忘了，索引不是只读的。每次插入一条新数据，数据库不仅要写进表，还得同步更新所有相关索引。更新、删除也一样。一个表如果有七八个索引，每写一次就要维护七八个结构，写入性能自然下降。
某电商后台的活动报名表，原本查询频繁，加了多个组合索引后查询快了，但到了活动开始瞬间，几千人同时提交，写入延迟飙升。最后发现是索引太多，每个INSERT都要更新多个B+树，成了瓶颈。
该不该加，得看实际场景
如果你的系统读多写少，比如报表分析库，那加索引基本只有好处。但如果是高频交易、实时日志这类写密集场景，就得权衡利弊。有时候宁可查得慢一点，也不能让写入卡住。
另外，无效索引也得清理。有些老项目里存在从未被使用的索引，白白浪费空间和写入开销。可以通过查询 information_schema 或性能视图来识别这些“僵尸索引”，再择机删除。
所以说，创建索引确实会影响性能，关键是怎么用。选对时间、选对方式、选对索引类型，才能既提速查询，又不至于拖垮系统。