千万级用户系统的SQL调优实战

Posted 2023-05-13

参考技术A

某系统专门通过各种条件筛选大量用户，接着对那些用户去推送一些消息：

通过一些条件筛选出大量用户，针对这些用户做推送，该过程较耗时-筛选用户过程。

用户日活百万级，注册用户千万级，而且若还没有进行分库分表，则该DB里的用户表可能就一张，单表上千万的用户数据。

对运营系统筛选用户的SQL：

一般存储用户数据的表会分为两张表：

有个子查询，里面针对用户的拓展信息表，即 users_extent_info 查下

最近一次登录时间 某个时间点

的用户，可以查询最近才登录过的用户，也可查询很长时间未登录的用户，然后给他们发push，无论哪种场景， 该SQL都适用。

然后在外层查询，用id IN子句查询 id 在子查询结果范围里的users表的所有数据，此时该SQL突然会查出很多数据，可能几千、几万、几十万，所以执行此类SQL前，都会先执行count：

然后内存里做个小批量，多批次读取数据的操作，比如判断如果在1000条以内，那么就一下子读取出来，若超过1000条，可通过LIMIT语句，每次就从该结果集里查1000条数据，查1000条就做次批量PUSH，再查下一波1000条。

就是在千万级数据量大表场景下，上面SQL直接轻松跑出来耗时几十s，不优化不行！

今天咱们继续来看这个千万级用户场景下的运营系统SQL调优案例，上次已经给大家说了一下业务背景 以及SQL，这个SQL就是如下的一个：

系统运行时，先COUNT查该结果集有多少数据，再分批查询。然而COUNT在千万级大表场景下，都要花几十s。实际上每个不同的MySQL版本都可能会调整生成执行计划的方式。

通过：

如下执行计划是为了调优，在测试环境的单表2万条数据场景，即使是5万条数据，当时这个SQL都跑了十多s，注意执行计划里的数据量

第二条执行计划的全表扫描结果表明一共扫到49651条，但全表扫描过程中，因为和物化临时表执行join，而物化临时表里就4561条数据，所以最终第二条执行计划的filtered=10%，即最终从users表里也筛选出4000多条数据。

先执行了子查询查出4561条数据，物化成临时表，接着对users主表全表扫描，扫描过程把每条数据都放到物化临时表里做全表扫描，本质在做join。

对子查询的结果做了一次物化临时表，落地磁盘，接着还全表扫描users表，每条数据居然跑到一个没有索引的物化临时表里，又做了一次全表扫描找匹配的数据。

对users表的全表扫描耗时吗？

对users表的每一条数据跑到物化临时表里做全表扫描耗时吗？

所以必然非常慢，几乎用不到索引。为什么MySQL会这样呢？

执行完上述SQL的EXPLAIN命令，看到执行计划之后，再执行：

显示出：

注意 semi join ，MySQL在这里，生成执行计划的时候，自动就把一个普通IN子句，“优化”成基于semi join来进行IN+子查询的操作。那对users表不是全表扫描了吗？对users表里每条数据，去对物化临时表全表扫描做semi join，无需将users表里的数据真的跟物化临时表里的数据join。只要users表里的一条数据，在物化临时表能找到匹配数据，则users表里的数据就会返回，这就是semi join，用来做筛选。

所以就是semi join和物化临时表导致的慢题，那怎么优化？

执行

关闭半连接优化，再执行EXPLAIN发现恢复为正常状态：

所以，其实反而是MySQL自动执行的semi join半连接优化，导致了极差性能，关闭即可。

生产环境当然不能随意更改这些设置，于是想了多种办法尝试去修改SQL语句的写法，在不影响其语义情况下，尽可能改变SQL语句的结构和格式，最终尝试出如下写法：

上述写法下，WHERE语句的OR后面的第二个条件，根本不可能成立，因为没有数据的latest_login_time -1，所以那不会影响SQL业务语义，但改变SQL后，执行计划也会变，就没有再semi join优化了，而是常规地用了子查询，主查询也是基于索引，同样达到几百ms 性能优化。

所以最核心的，还是看懂SQL执行计划，分析慢的原因，尽量避免全表扫描，务必用上索引。

千万级SQL Server数据库表分区的实现

千万级SQL Server数据库表分区的实现

2010-09-10 13:37 佚名 数据库 字号：T | T

一般在千万级的数据压力下，分区是一种比较好的提升性能方法。本文将介绍SQL Server数据库表分区的实现。

AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验

 

最近使用SQL SERVER一个的缓存，数据量一天100w的速度增长，同时接受客户查询，速度由于数据量越来越大越来越慢，这里感谢  KillKill 和 邀约, 最近读了一套书不错，感兴趣的同学可以读读<<活法>>

回顾下经常使用的索引

一 .聚集索引

聚集索引的页级别包含了索引键，还包含数据页，因此，关于 除了键值以外聚集索引的叶级别还存放了什么的答案就是一切，也就是说，每行的所有字段都在叶级别种。
另一种说话是:数据本身也是聚集索引的一部分，聚集索引基于键值保持表中的数据有序。

SQL SERVER 中，所有的聚集索引都是唯一的，如果在创建聚集索引时没有指定UNIQUE 关键字，SQL SERVER 会在需要时通过往记录中添加一个唯一标识符(Uniqueifier)在内部保证索引的唯一性，该唯一标识符是一个4字节的值，作为附加在聚集索引键的字段添加到数据中，只有那些声明为索引键字段并拥有重复值的行才会被添加。

二 .非聚集索引

对于非聚集索引，叶级别不包含全部的数据。除了键值以外，每个叶级别(树的最低层)中的索引行包含了一个书签(bookmark),告诉SQL Server 可以在哪里找到与索引键相应的数据行。一个书签课能有两种格式。如果表上存在聚集索引，书签就是相应的数据行的聚集索引键。如果表是堆(heap)结构 ，就是没有聚集索引的情况下 ，书签就是一个行标识符 row identifier,rid ，以 文件号 页号 槽号 的格式来定位实际的行。

非聚集索引的存在与否并不影响数据分页的组织，因此每张表上并不像聚集索引那样只局限于拥有一个非聚集索引，SQL  Server 2005  每张表能够包含249 个非聚集索引 SQL Server 2008 每张表能够包含999 个非聚集索引 ，但是实际上所用到的比这个数要少的多。

三 .包含索引

索引键字段数量限制是16个，总共900个字节大小 ，包含性列只在叶级别中出现而且不以任何方式控制索引行的排序。它们的目的是使叶级别能够包含更多的信息从而更大地发挥覆盖索引(Covering index)的索引调优能力.覆盖索引是一种非聚集索引，在其叶级别就可以找到满足查询的全部信息，这样sql server就根本没有必要访问数据分页了，在一些情况下 sql serer 会悄悄的为索引添加一个包含性列。这可能发生在索引建立于分区表 也就是我今天是发的博客 O(∩_∩)O (partitioned table )上没有指定 on filegroup  或者 no partition_scheme  的情况下。

一 .SQL SERVER 表分区介绍：

SQL Server  引入的表分区技术，让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理性能以优化查询性能……

二 .SQL SERVER 数据库表分区由三个步骤来完成:

1.创建分区函数

2.创建分区架构

3.对表进行分区

基于缓存更新机制，我使用时间来进行分区，这里大家根据业务的要求使用合适的字段来作为分区

创建数据库分区文件数量，这里存储一年的数据分成十二个分区，需要现在D盘建立好Data 的文件夹 里面包含Primary 文件夹和 FG1 FG2 FG3 FG4............

1. IF  EXISTS (SELECT name FROM sys.databases WHERE name = N‘AirAvCache‘)  
2. DROP DATABASE [AirAvCache]  
3. GO  
4. CREATE DATABASE [AirAvCache]  
5. ON PRIMARY 
6. (NAME=‘Data Partition DB Primary FG‘,  
7. FILENAME=  
8. ‘D:\Data\Primary\AirAvCache Primary FG.mdf‘,  
9. SIZE=5,  
10. MAXSIZE=500,  
11. FILEGROWTH=1 ),  
12. FILEGROUP [AirAvCache FG1]  
13. (NAME = ‘AirAvCache FG1‘,  
14. FILENAME =  
15. ‘D:\Data\FG1\AirAvCache FG1.ndf‘,  
16. SIZE = 5MB,  
17. MAXSIZE=500,  
18. FILEGROWTH=1 ),  
19. FILEGROUP [AirAvCache FG2]  
20. (NAME = ‘AirAvCache FG2‘,  
21. FILENAME =  
22. ‘D:\Data\FG2\AirAvCache FG2.ndf‘,  
23. SIZE = 5MB,  
24. MAXSIZE=500,  
25. FILEGROWTH=1 ),  
26. FILEGROUP [AirAvCache FG3]  
27. (NAME = ‘AirAvCache FG3‘,  
28. FILENAME =  
29. ‘D:\Data\FG3\AirAvCache FG3.ndf‘,  
30. SIZE = 5MB,  
31. MAXSIZE=500,  
32. FILEGROWTH=1 ),  
33. FILEGROUP [AirAvCache FG4]  
34. (NAME = ‘AirAvCache FG4‘,  
35. FILENAME =  
36. ‘D:\Data\FG4\AirAvCache FG4.ndf‘,  
37. SIZE = 5MB,  
38. MAXSIZE=500,  
39. FILEGROWTH=1 ),  
40. FILEGROUP [AirAvCache FG5]  
41. (NAME = ‘AirAvCache FG5‘,  
42. FILENAME =  
43. ‘D:\Data\FG5\AirAvCache FG5.ndf‘,  
44. SIZE = 5MB,  
45. MAXSIZE=500,  
46. FILEGROWTH=1 ),  
47.  
48. FILEGROUP [AirAvCache FG6]  
49. (NAME = ‘AirAvCache FG6‘,  
50. FILENAME =  
51. ‘D:\Data\FG6\AirAvCache FG6.ndf‘,  
52. SIZE = 5MB,  
53. MAXSIZE=500,  
54. FILEGROWTH=1 ),  
55.  
56.  
57. FILEGROUP [AirAvCache FG7]  
58. (NAME = ‘AirAvCache FG7‘,  
59. FILENAME =  
60. ‘D:\Data\FG7\AirAvCache FG7.ndf‘,  
61. SIZE = 5MB,  
62. MAXSIZE=500,  
63. FILEGROWTH=1 ),  
64.  
65. FILEGROUP [AirAvCache FG8]  
66. (NAME = ‘AirAvCache FG8‘,  
67. FILENAME =  
68. ‘D:\Data\FG8\AirAvCache FG8.ndf‘,  
69. SIZE = 5MB,  
70. MAXSIZE=500,  
71. FILEGROWTH=1 ),  
72.  
73. FILEGROUP [AirAvCache FG9]  
74. (NAME = ‘AirAvCache FG9‘,  
75. FILENAME =  
76. ‘D:\Data\FG9\AirAvCache FG9.ndf‘,  
77. SIZE = 5MB,  
78. MAXSIZE=500,  
79. FILEGROWTH=1 ),  
80.  
81. FILEGROUP [AirAvCache FG10]  
82. (NAME = ‘AirAvCache FG10‘,  
83. FILENAME =  
84. ‘D:\Data\FG10\AirAvCache FG10.ndf‘,  
85. SIZE = 5MB,  
86. MAXSIZE=500,  
87. FILEGROWTH=1 ),  
88.  
89. FILEGROUP [AirAvCache FG11]  
90. (NAME = ‘AirAvCache FG11‘,  
91. FILENAME =  
92. ‘D:\Data\FG11\AirAvCache FG11.ndf‘,  
93. SIZE = 5MB,  
94. MAXSIZE=500,  
95. FILEGROWTH=1 ),  
96.  
97. FILEGROUP [AirAvCache FG12]  
98. (NAME = ‘AirAvCache FG12‘,  
99. FILENAME =  
100. ‘D:\Data\FG12\AirAvCache FG12.ndf‘,  
101. SIZE = 5MB,  
102. MAXSIZE=500,  
103. FILEGROWTH=1 ) 

创建好后如图：

打开FG1 文件夹 看到多了AirAvCacheFG1.ndf 文件

创建分区函数

1. USE AirAvCache  
2. GO   
3.  
4. -- 创建函数  
5.  
6. CREATE PARTITION FUNCTION [AirAvCache Partition  Range](DATETIME)  
7. AS RANGE LEFT FOR VALUES (‘2010-09-01‘,‘2010-10-01‘,‘2010-11-01‘,
8. ‘2010-12-01‘,‘2011-01-01‘,‘2011-02-01‘,‘2011-03-01‘,‘2011-04-01‘,
9. ‘2011-05-01‘,‘2011-06-01‘,‘2010-07-01‘); 

创建分区架构

1. CREATE PARTITION SCHEME [AirAvCache Partition Scheme]  
2. AS PARTITION [AirAvCache Partition  Range]  
3. TO ([AirAvCache FG1], [AirAvCache FG2], [AirAvCache FG3],[AirAvCache FG4],[AirAvCache FG5],[AirAvCache FG6],[AirAvCache FG7],[AirAvCache FG8],  
4. [AirAvCache FG9],[AirAvCache FG10],[AirAvCache FG11],[AirAvCache FG12]); 

创建一个使用AirAvCache Partitiion Scheme 架构的表

1. CREATE TABLE [dbo].[AvCache](  
2.     [CityPair] [varchar](6)  NOT NULL,  
3.     [FlightNo] [varchar](10)  NULL,  
4.     [FlightDate] [datetime] NOT NULL,  
5.     [CacheTime] [datetime] NOT NULL   DEFAULT (getdate()),  
6.     [AVNote] [varchar](300)  NULL 
7. )  ON [AirAvCache Partition Scheme] (FlightDate);   
8. --注意这里使用[AirAvCache Partition Scheme]架构，根据FlightDate 分区 

查询分区情况

1. -- 查看使用情况   
2. SELECT *, $PARTITION.[AirAvCache Partition  Range](FlightDate)  
3. FROM dbo.AVCache 

可以看到9 月和 10 月已经分开了。