SQL数据库优化那些事儿，怎么让数据操作跑得更快点吧

说到让数据库跑得更快,这确实是每个和数据库打交道的人都会关心的大问题，想象一下，你点个外卖，结果半个小时还在“商家接单中”，是不是很恼火？数据库慢了，用户就是这种感觉，下面我就结合一些常见的经验和网上技术社区像知乎、CSDN上常被提到的点，用大白话聊聊怎么给数据库提速。

最立竿见影的招数：建索引。 这就像给一本厚厚的书加上目录，如果没有目录，你想找某个章节，只能一页一页翻，那得多慢啊，数据库里的表就是那本书，数据就是书里的内容，索引就是这个目录，你经常根据用户的手机号来查信息，那就在手机号这个字段上建个索引，这样数据库就不用扫描整个表，直接翻“目录”就能定位到数据，速度飞快。

索引不是越多越好,知乎上有个生动的比喻：索引就像书里的目录，每多一个索引，就像给书多加一份目录（比如按人名一份，按地名一份），书的内容每变一次（比如增删一页），所有的目录都得更新一次，这就会拖慢写入（增加、修改、删除）的速度，索引要建在那些经常被用来查询（WHERE条件）或者排序（ORDER BY）的列上，对于那些很少被查询或者数据量特别小的表，建索引反而可能是负担。

要写好SQL语句本身。 很多慢的问题，其实是语句写得不好导致的，这里有几个常见的坑：

1. *避免用 `SELECT **，很多人图省事，直接写SELECT *，把所有的列都查出来，但很多时候你并不需要所有数据，这就好比你只想看看书的封面，却把整本书都搬过来了，浪费力气和带宽，应该需要什么字段就查什么字段，比如只查SELECT id, name`。
2. 小心使用 LIKE，尤其是以通配符 开头的模糊查询，LIKE '%关键字%'，这种查询就像让你在一本没有目录的书里找一个词，只能从头到尾逐字扫描，我们称之为“全表扫描”，效率极低，如果实在要用，尽量写成 LIKE '关键字%'，这样如果该字段有索引，还是可能用上的。
3. 注意表连接（JOIN），连接表的时候，一定要确保连接条件（ON 后面的字段）上有索引，连接多个大表时，如果没索引，数据库就得进行“嵌套循环”，好比是两层甚至三层循环去找数据，性能是指数级下降，CSDN上很多文章都强调，JOIN是性能问题的重灾区。

说说表结构的设计。 这在最开始就要规划好。

• 适当拆分表：如果一个表字段太多，有几千万行，查询起来就会很笨重，可以考虑把一些不常用的、或者很长的字段（比如文章内容、商品详情）拆分到另外一张表里，需要的时候再关联查询，这叫“垂直拆分”。
• 选择合适的数据类型：能用整数（INT）就别用字符串（VARCHAR），能用短字符串就别用长字符串（TEXT），数据类型越小，占用的磁盘空间和内存就越少，数据库处理起来自然越快，比如存储状态，用 0,1,2 这样的数字就比用 '未开始'，'进行中'，'已完成' 这样的中文要高效。

数据库服务器本身的配置和硬件也很关键。 这就像电脑配置低了，再好的软件也跑不快。

• 内存（RAM）：数据库会把常用的数据缓存在内存里，内存越大，能缓存的数据就越多，直接从内存读数据比从硬盘读要快成千上万倍，给数据库分配足够的内存是提升性能的硬道理。
• 硬盘（Disk）：传统机械硬盘（HDD）的读写速度远不如固态硬盘（SSD），对于读写频繁的数据库，换上SSD会有质的飞跃。

是一些进阶但很重要的思路。

• 读写分离：当网站或应用访问量非常大时，可以把数据库分成一个主库（负责写入数据，如增、删、改）和多个从库（负责读取数据，如查询），这样写操作和读操作分开了，减轻了单台数据库的压力，很多大型互联网公司都采用这种架构。
• 清理历史数据：数据库不是垃圾桶，不能只存不删，对于过期的日志、无效的订单等历史数据，要定期归档或清理，表里的数据少了，查询和维护的速度自然就上去了，这招通常效果非常明显。

让SQL数据库跑得快,是一个系统工程，它涉及到从最基础的SQL语句编写、索引创建，到表结构设计，再到服务器硬件和架构的方方面面，没有一个一劳永逸的银弹，需要根据自己业务的具体情况，像老中医看病一样，不断地观察（监控慢查询）、诊断（分析执行计划）、下药（采取优化措施），平时多注意这些点，就能让你的数据操作告别龟速，飞驰起来。