MySQL优化之索引优化(九)

159 阅读2分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 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除了简单,其他都是缺点,总体来看存在以下几个方面的问题:

  1. 可靠性不高:存在自增ID回溯的问题,这个问题直到最新版本的MySQL8.0才修复。
  2. 安全性不高:对外暴露的接口可以很容易猜测对应的信息。比如/user/1/这样的接口,可以非常容易猜出用户ID的值为多少,总用户数量多少,也可以非常容易的通过接口进行数据的爬取。
  3. 性能差:自增ID的性能较差,需要在数据库服务器端生成。
  4. 交互多:业务上还需要额外执行一次类似last_insert_id的函数才能知道刚才插入的自增值是多少,需要多一次的网络交互。在海量并发系统中,多一条SQL,就多一次性能上的开销。
  5. 局部唯一性:自增ID是局部唯一,只有当前数据库实例中唯一,而不是全局唯一,在任意服务器间都是唯一的。对于目前分布式系统来说,这是不合理的。

今天先学习到这里,明天继续。