目录
在数据库设计中，用UUID字符串和INT自增做主键，你怎么看它们的区别？"
同一条SQL，在我们开发环境是很快的，但是如果放到生产环境就很慢，这个时候应该从哪几个角度去考虑？
[什么情况下 MySQL 优化器会放弃使用索引？](#什么情况下 MySQL 优化器会放弃使用索引？)
[一个慢查询，EXPLAIN 看到走了索引但还是慢，可能是什么原因？](#一个慢查询，EXPLAIN 看到走了索引但还是慢，可能是什么原因？)
在数据库设计中，用UUID 字符串和 INT 自增做 主键 ，你怎么看它们的区别？"
UUID的核心优势是全局唯一的，是随机字符串，天然无序
INT自增的核心优势是严格递增有序的，写入性能高
可以从三个方面谈谈二者的区别
内存 方面：
int所占用空间更小
UUID所占用空间更大
性能方面：
int做主键，是按顺序递增的，是按顺序写入页的，发生页分裂的频率低，写入性能较高
UUID做主键，由于本身是随机字符串，是随机写入页的，发生页分裂的频率高，写入性能会随着数据量的增加而下降
使用场景方面：
UUID更适合分布式与微服务的场景，因为UUID字符串是一定不会重复的。
int更适合于单体架构，追求写入性能。因为在分布式系统中，在进行表的合并时，不同表的id可能会冲突。
同一条SQL，在我们开发环境是很快的，但是如果放到生产环境就很慢，这个时候应该从哪几个角度去考虑？
角度：
1.考虑索引是否失效
2.看看服务器的指标，比如CPU,磁盘I/O是不是超负荷了
3.考虑是不是锁等待导致的
排查思路：先看是不是某个时间点突然出现的。如果是，查一下那个时间有没有发布任务。然后看慢查询日志，找出最频繁的几条 SQL。用 EXPLAIN 分析执行计划，检查索引有没有失效。同时看一下服务器指标，CPU、磁盘 I/O是不是超负荷。如果是锁等待导致的，用 SHOW PROCESSLIST 进行排查，关注time和state字段。
锁等待是指：一个数据库事务（事务B）试图获取（锁定）某个数据资源（一行数据、一个间隙或一张表）时，发现这个资源已经被另一个尚未完成的事务（事务A）以不兼容的模式锁定了。此时，事务B无法继续执行，必须进入等待队列，直到事务A释放了它所需的锁。
什么情况下 MySQL 优化器 会放弃使用索引？
MySQL优化器是基于成本估算的，它认为全表扫描更快就不走索引。典型场景是查询结果集占总数据量比例太高，比如表里 100 万条数据，查询条件能匹配 60 万条，如果没有索引覆盖，就要多一次回表操作。此时走索引的成本是要大于全表扫描的成本的
一个慢查询，EXPLAIN 看到走了索引但还是慢，可能是什么原因？
-
回表次数太多，虽然走了二级索引，但查出来几十万行每行都要回表，回表是随机IO，会消耗大量时间。
-
索引选择性差，比如 status 字段只有几个值，走索引过滤效果不好。
就比如使用姓名在全国去查人，你可能会查出很多同名的人，索引过滤效果不好
-
数据量太大，导致索引数量过多，内存装不下这么多索引，需要频繁去读磁盘中的不在内存的索引，在进行后续查询。
-
EXPLAIN 是估算，实际执行可能和估算不一样。
-
返回数据量大，导致网络传输耗时。