开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第18天，点击查看活动详情
前言
上篇我们学习了MySQL中的数据库优化之索引优化。有兴趣的小伙伴可以阅读(MySQL优化之索引优化（八）)。
下面我们继续学习MySQL中的数据库优化之索引优化。
SELECT *
在表查询中，建议明确字段，不要使用作为查询的字段列表，推荐使用SELECT<字段列表>查询。因为MySQL在解析的过程中，会通过查询数据字典将按序转换成所有列名，这会大大的耗费资源和时间。另外无法使用覆盖索引。
LIMIT 1
针对的是会扫描全表的SQL语句，如果可以确定结果集中只有一条，那么加上LIMIT 1的时候，当找到一条结果的时候就不会继续扫描了，这样会加快查询速度。
如果数据表已经对字段建立了唯一索引，那么可以通过索引进行查询，不会全表扫描的话，就不需要加上MILIT 1了。
COMMIT
只要有可能得话，在程序中尽量多使用COMMIT，这样程序的性能得到提高，需求也会因为COMMIT所释放的资源而减少。
COMMIT会有所释放的资源包含：
- 回滚段上用于恢复数据的信息
- 被程序语句获得的锁
- redo/undo log buffer中的空间
- 管理上述3种资源中的内部花费。
主键设计
自增ID做主键的问题
自增ID做主键，简单易懂，几乎所有的数据库都支持自增类型，只是实现上各自有所不同而已。自增ID除了简单，其他都是缺点，总体来看存在以下几个方面的问题：
- 可靠性不高：存在自增ID回溯的问题，这个问题直到最新版本的MySQL8.0才修复。
- 安全性不高：对外暴露的接口可以很容易猜测对应的信息。比如/user/1/这样的接口，可以非常容易猜出用户ID的值为多少，总用户数量多少，也可以非常容易的通过接口进行数据的爬取。
- 性能差：自增ID的性能较差，需要在数据库服务器端生成。
- 交互多：业务上还需要额外执行一次类似last_insert_id的函数才能知道刚才插入的自增值是多少，需要多一次的网络交互。在海量并发系统中，多一条SQL，就多一次性能上的开销。
- 局部唯一性：自增ID是局部唯一，只有当前数据库实例中唯一，而不是全局唯一，在任意服务器间都是唯一的。对于目前分布式系统来说，这是不合理的。
今天先学习到这里，明天继续。
