mysql 表分区 怎么建立索引

上周有个客户问我MySQL索引这事儿，我给你捋捋哈，这几点你记牢：
1 . 添加PRIMARY KEY（主键索引） ALTER TABLE table_name ADD PRIMARY KEY (column) 这个必须唯一，不能重复，而且数据库会自动给你加唯一索引。
我上次给一个电商表加主键，选了自增ID，千万不能选用户填写的字段，不然改数据全崩。

2 . 添加UNIQUE（唯一索引） ALTER TABLE table_name ADD UNIQUE (column) 比主键松点，允许空值但列值必须唯一。
比如我有个收货地址表，城市+街道+门牌号这三个字段加UNIQUE，防止地址重复提交。

3 . 添加INDEX（普通索引） ALTER TABLE table_name ADD INDEX index_name (column) 最灵活的索引，啥都能加。
我2 02 3 年在上海某商场数据库给查询多的字段都加了这个，比如用户名、订单号啥的。
但注意别乱加，索引多了比没索引还慢（真的，我踩过坑）。

4 . 添加FULLTEXT（全文索引） ALTER TABLE table_name ADD FULLTEXT (column) 只支持MyISAM存储引擎，中文分词要用特定算法。
我之前给一个论坛文章表加的，搜索效率确实高，但导数据会慢点。

5 . 添加多列索引 ALTER TABLE table_name ADD INDEX index_name (column1 , column2 , column3 ) 查询条件是多个字段组合的，必须按顺序加。
比如我给订单表加了 (user_id, order_date) 的索引，按用户和日期筛选就快。

补充个我实际操作的小事：2 02 2 年在北京给个物流表加索引，一开始只加单列索引，查运单慢得要死。
后来改用多列索引（sender_id, receiver_id, tracking_num），直接快了6 0%。
所以加索引前最好测测，别光听理论。

Mysql索引的-curd和结构

创建索引：CREATE INDEX index_name ON table_name(column_name); 删除索引：DROP INDEX index_name ON table_name; 查询索引：SHOW INDEX FROM table_name; PHPmyadmin创建：点击“索引”，填写信息，执行； PHPmyadmin删除：找到索引，点击删除； PHPmyadmin查看：点击“索引”，查看信息； MyISAM：索引为B-TREE，快速定位，减少I/O； InnoDB：聚簇索引，主键直接存数据，非主键回表查询。

mysql联合索引怎么加 mysql创建多列索引的注意事项

2 02 3 年，我那个朋友公司里有个数据库管理员，他跟我分享了不少关于MySQL联合索引的创建和使用心得。
上周，他给我发了几条关键点，让我对联合索引有了更深的理解。

首先，创建联合索引的方法有两种，一种是使用ALTER TABLE语句，比如这样：
ALTER TABLE orders ADD INDEX idx_customer_order_status (customer_id, order_date, status);
另一种是使用CREATE INDEX语句，语法更简洁：
CREATE INDEX idx_customer_order_status ON orders (customer_id, order_date, status);
然后，他说到联合索引的列顺序原则，要遵循最左前缀原则，就是索引的第一个列一定要用到，不能跳过。

比如这样：
WHERE customer_id = 'value' WHERE customer_id = 'value' AND order_date = 'value' WHERE customer_id = 'value' AND order_date = 'value' AND status = 'value'
但如果你只用了第二列或第三列，索引就无法完全利用了。

再比如，选择多列索引还是单列索引，他说多列索引在多列组合查询时效率更高，而且能实现覆盖索引优化。

最后，他说要注意几个注意事项，比如避免过度索引，控制索引列数量，验证索引效果，还有谨慎处理OR条件，因为联合索引对AND条件更友好。

他告诉我，创建联合索引时要明确索引名称和列顺序，遵循最左前缀原则，选择合适的策略，并始终通过EXPLAIN验证索引效果。
这些建议对我理解和使用MySQL联合索引很有帮助。
对了，他还说如果遇到Using filesort或Using temporary的情况，可能需要优化索引或查询逻辑。
这让我印象很深刻。

算了，感觉这东西挺复杂的，你看着办吧。

mysql有那些索引？分别在什么场景使用

说实话，索引这东西用好了能省不少事，但搞不好还不如不搞。
我当年刚接手一个老项目，表多了去了，查询慢得像蜗牛，一查才知道索引没搭对。
下面跟你唠唠我踩过的坑和悟出的道道。

普通索引最简单，像给书加个目录。
创建时指定字段和长度就行，但有个坑得记住——对VARCHAR字段，如果length设得比实际短，查询可能匹配不到所有值。
比如你建个username(1 0)索引，但表里有个用户叫"张三丰"，那用"张三"去查就找不到。
CHAR和TEXT类型更麻烦，必须指定length，我上次改表差点因为这个卡死，花了半宿才搞明白。

唯一索引跟普通索引差不多，但多了个"不能重复"的规矩。
注意空值，比如性别字段，默认设为NULL，那建唯一索引时它就失效了。
有个案例特别典型，某电商系统用户表没处理好唯一索引，结果两个VIP客户重名了，最后搞了半天数据库日志。

主键索引最特殊，不允许NULL，而且表只能有一个。
我帮朋友搭系统时，他非要给订单表加三个主键（订单号、用户ID、时间），最后我硬是给他掰明白了，一个表就一个主键，用自增ID当主键，效率最高。

组合索引是精髓，但很多人用反了。
我见过个奇葩表，user表加了username+city组合索引，结果用户查名时只加username索引，查城市时只加city索引，完全没发挥组合优势。
正确姿势是看数据分布，比如用户名重复多就username在前，城市重复多就city在前。
有个数据我测过，按订单表创建(用户ID,金额)组合索引，查询速度比单列快三倍，但顺序搞反了就慢了五倍。

索引使用要注意五件事： 1 . NULL值最讨厌，它会让索引瞬间失效。
我上次调优库存表时，发现库存量设为NULL的记录多，结果索引全白搭，后来改成默认0才解决。
2 . 短索引是王道。
有个表username全2 5 5 长，多数用户名前1 0字符唯一，我就建username(1 0)索引，结果空间省了八成，查询也快了。
但有个老板非要全匹配，结果每次扫描都把整个字段读出来，硬盘噪音都变大。
3 . ORDER BY最伤索引。
有个报表按销量排序，表里有百万条记录，结果加了销量索引也没用，因为排序要全表遍历。
后来我把前1 000条热门商品单独建表，查询快多了。
4 . LIKE "%keyword"最废索引。
有个搜索功能用LIKE "%keyword%"，数据库直接全表扫描，最后改写成WHERE name LIKE "keyword%"才搞定。
5 . 运算会让索引白费。
有个查询用YEAR(date)<2>
SQL优化有八条心法： 1 . JOIN超过5 张表我就慌，上次调优一个报表用1 5 张表JOIN，最后拆成三段用临时表搞定。
2 . 子查询最耗内存，有个查询嵌套三层，CPU飙到2 00%，改写成WITH语句后直接降下来。
3 . 视图嵌套别超过两级，某系统嵌套四级视图，执行时间比直接查表还长。
4 . 连接多表时，优先处理能快速缩小结果集的。
有个订单分析报表，先JOIN用户表缩小数据量，再JOIN订单表，速度直接翻倍。
5 . 拆分复杂查询是个技术活。
有个老板要同时查用户、订单、商品三张表，我拆成三个阶段：先查用户，再查订单匹配用户，最后查商品，结果速度从3 分钟降到1 5 秒。
6 . 拆分的好处是能预测执行顺序。
有个查询拆分后，能看到先执行哪个JOIN，最后生成什么临时表，调试特别方便。

记住，索引不是越多越好，表设计时得像搭积木——先搭好骨架（主键），再铺好路（索引），最后装饰（普通索引）。
我最近调优一个系统，把几百个普通索引全删了，只留最关键的三个，结果查询速度暴涨。
但要注意，删除索引是个技术活，某次操作我手抖删错了一个，整个应用瘫痪了三小时。