mysql怎么增加索引

结论： MySQL ALTERTABLE 添加索引，语法是 ALTERTABLE table_name ADD INDEX index_name(column_name1 , column_name2 , ...)。
默认是 B-树索引，适合等值、范围、排序、分组查询。
哈希索引仅等值查询快，全文索引文本搜索用。
加索引在频繁查询列，高选择性列，遵循最左前缀原则。
注意性能影响，避免过度索引，主键唯一约束默认索引。
删除索引用 DROP INDEX，查看用 SHOW INDEX。
设计索引要结合查询和数据量，EXPLAIN 分析查询计划。

如何在mysql中使用单列索引和复合索引

说实话，聊MySQL索引这事儿，我当年刚入行时也头大。
但真跑着跑着，你就摸出门道了。
单列索引和复合索引就像两把不同用途的锤子，用对了能省不少事儿。

先说单列索引。
我之前带过个项目，用户表有上百万人。
当时有个需求，得根据email快速查用户。
直接在email上建单列索引就解决了。
建表时加或者建表后加都行，比如这样：
sql CREATE INDEX idx_email ON users(email);
查询时自然能用到：
sql SELECT FROM users WHERE email = 'abc@example.com';
但有意思的是，单列索引有个硬伤。
比如你要查 WHERE email = 'a' AND name = 'b'，这个索引就不管用了。
我当时接手一个老系统，就有个查询因为用了不合适的单列索引，跑得飞慢。
后来改成复合索引才解决。
所以记住，单列索引只适合独立查询频繁的字段。

复合索引就复杂点。
我另一个项目是电商系统，经常要查 WHERE user_id = 1 AND status = 'paid'。
这种多条件组合查询，复合索引就派上用场了：
sql CREATE INDEX idx_user_status ON orders(user_id, status);
但复合索引有个怪癖，叫"最左前缀原则"。
你要是查 WHERE status = 'paid'，这个索引就白建了。
我见过有团队因为这个踩坑，明明建了索引，EXPLAIN却显示没使用。
后来发现是他们查询写反了顺序。
所以创建复合索引时，得想清楚最常怎么查。

至于索引策略，我建议这么选。
像用户表的email、手机号这种，肯定要单列索引。
订单表这种，经常联合查 user_id 和 status，就建复合索引。
但别瞎建，比如你已经有了 (user_id, status) 索引，就别再为 user_id 单独建索引了，纯属浪费空间。

验证索引最靠谱的是EXPLAIN。
我有个习惯，写完SQL必EXPLAIN。
比如：
sql EXPLAIN SELECT FROM orders WHERE user_id = 1 AND status = 'paid';
看 type 字段是不是 ref 或 range，key 对不对上你建的索引名，rows 数量是不是在可控范围内。
有回我接手个系统，EXPLAIN显示全表扫描，一查发现索引名写错了，整晚没睡好。

说到底，索引这东西就像给数据库装导航。
单列索引是直达某个路口的短途车，复合索引是能带你绕城走的多条件巴士。
用多了自然知道，哪个路口堵，哪条路省油。
不过千万别贪多，我见过最极端的案例，一个表建了上百个索引，结果插入一条数据要等半天。
所以啊，索引是双刃剑，用好了能飞，用不好...呵呵。

mysql 状态类型字段怎么建索引

上周有个客户问我，在MySQL里面对那些只有0和1 的状态类型字段，到底建不建索引。
我给他分析了一下，这事儿还真得看情况。

首先，你提到的，如果这个字段的数据量很大，比如超过了总数据的2 0%，单纯建个索引可能效果不明显。
因为这时候数据分布比较均匀，索引的优势就不那么突出了。

再来说更新频率，如果这个字段经常变动，每次更新不仅要更新数据，还要更新索引，这就可能导致性能损失。
所以，如果这个字段修改很频繁，建索引可能不是最佳选择。

但如果确实需要通过这个字段查询，那我们可以考虑让这个字段的值分布得更均匀，这样索引的效果会更好。
而且，你提到的，如果能把数据类型从整型改成枚举，不仅存储空间能减少，索引效率也可能提高，因为枚举类型会自动创建索引。

还有一点，就是可以考虑复合索引。
如果这个状态字段经常和其他字段一起出现，我们可以创建一个包含这些字段的复合索引，这样可以提高查询效率。

至于位图索引，它适合数据分布非常稀疏的情况，能大大减少索引的存储空间，提高查询性能。
不过，这个方法可能不适用于所有场景。

总之，对于状态类型字段的索引优化，得具体问题具体分析。
得权衡查询模式、数据量和更新频率，才能找到最佳的性能方案。
反正你看着办吧，这事儿没有统一的标准答案。
我还在想这个问题，毕竟每个数据库的情况都不同。