MySQL性能优化思路和工具

　　一、优化思路
　　作为架构师或者开发人员，说到数据库性能优化，你的思路是什么样的？
　　或者具体一点，如果在面试的时候遇到这个问题：你会从哪些维度来优化数据库，你会怎么回答？
　　我们在第一节课开始的时候讲了，这四节课的目标是为了让大家建立数据库的知识体系，和正确的学习调优的思路。
　　我们说到性能调优，大部分时候想要实现的目标是让我们的查询速度更快。一个查询的动作又是有很多个环节组成的，每个环节都会消耗时间，我们在第一节课讲SQL语句的执行流程的时候已经分析过了。
　　我们要减少查询所消耗的时间，就要从每一个环节入手。
　　二、连接配置优化
　　第一个环节是客户端连接到服务端，连接这一块有可能会出现什么样的性能问题？有可能是服务端连接数不够导致应用程序获取不到连接。比如报了一个Mysql：error1040：Toomanyconnections的错误。
　　我们可以从两个方面来解决连接数不够的问题：
　　1、从服务端来说，我们可以增加服务端的可用连接数。
　　如果有多个应用或者很多请求同时访问数据库，连接数不够的时候，我们可以：
　　（1）修改配置参数增加可用连接数，修改maxconnections的大小：
　　showvariableslikemaxconnections；修改最大连接数，当有多个应用连接的时候
　　（2）或者，或者及时释放不活动的连接。交互式和非交互式的客户端的默认超时时间都是28800秒，8小时候，我们可以把这个值调小。showglobalvariableslikewaittimeout；及时释放不活动的连接，注意不要释放连接池还
　　在使用的连接
　　2、从客户端来说，可以减少从服务端获取的连接数，如果我们想要不是每一次执行SQL创建一个新的连接，应该怎么做？
　　这个时候我们可以引入连接池，实现连接的重用。
　　我们可以在哪些层面使用连接池？ORM层面（MyBatis自带了一个连接池）；或者使用专用的连接器池工具（阿里的Druid、SpringBoot2。x版本默认的连接池Hikari、老牌的DBCP和C3P0）。
　　我们这里说到了从数据库配置的层面去优化数据库。不管是数据库本身的配置，还是安装这个数据库服务的操作系统的配置，对于配置进行优化，最终的目标都是为了更好地发挥硬件本身的性能，包括CPU、内存、磁盘、网络。
　　在不同的硬件环境下，操作系统不同MySQL的参数的配置是不同的，没有标准的配置。
　　在我们这几天的课程里面也接触了很多的MySQL和InnoDB的配置参数，包括各种开关和数值的配置，大多数参数都提供了一个默认值，比如默认的bufferpoolsize，默认的页大小，InnoDB并发线程数等等。
　　这些默认配置可以满足大部分人的需求，除非有特殊的需求，在清楚参数的含义的情况下再去修改它。修改配置的工作一般由专业的DBA完成。
　　至于硬件本身的选择，比如使用固态硬盘，搭建磁盘阵列，选择特定的CPU幸好这些，不是我们开发人员关注的重点，这个我们就不做过多的介绍了。
　　除了合理设置服务端的连接数和客户端的连接池大小之外，我们还有哪些减少客户端跟数据库服务端的连接数的方案呢？
　　我们可以引入缓存。三、缓存架构优化
　　缓存
　　在应用系统的并发数非常大的情况下，如果没有缓存，会造成两个问题：一方面是会给数据库带来很大的压力。另一方面，从应用的层面来说，操作数据的速度也会受到影响。
　　我们可以用第三方的缓存服务来解决这个问题，例如Redis。
　　运行独立的缓存服务，属于架构层面的优化。
　　为了减少单台数据库服务器的读写压力，在架构层面我们还可以做其他哪些优化措施？
　　主从复制
　　如果单台数据库服务满足不了访问需求，那我们可以做数据库的集群方案。
　　集群的话必然会面临一个问题，就是不同的节点之间数据一致性的问题。如果同时读写多台数据库节点，怎么让所有的节点数据保持一致？
　　这个时候我们需要用到复制技术（replication），被复制的节点称为master，复制的节点称为slave。
　　主从复制是怎么实现的呢？在第一节课我们说过，更新的语句会记录下来binlog，它是一种逻辑日志。
　　有了这个binlog，从服务器会获取主服务器的信息binlog文件，然后解析里面的SQL语句，再从服务器上面执行一遍，保持与主从的数据一致。
　　这里面涉及到三个线程，连接到master获取binlog，并且解析binlog写入中继日志，这个线程叫做IO线程。
　　Master节点上有一个logdump线程，是用来发送binlog给slave的。
　　从库的SQL线程，是用来读取relaylog，把数据写入到数据库里的。
　　这个是主从复制涉及到的三个线程。
　　做了主从复制的方案之后，我们只把数据写入master节点，而读的请求可以分担到slave节点。我们把这种方案叫做读写分离。
　　读写分离可以一定程度地减轻数据库服务器的访问压力，但是需要特别注意数据一致性的问题。
　　我们在做了主从复制之后，如果单个master节点或者单张表存储的数据过大的时候，比如一张表有上亿的数据，单张表的查询性能还是会下降，我们要进一步对单台数据库节点的数据进行拆分，这个就是是分库分表。
　　分库分表
　　垂直分库，减少并发压力。水平分表，解决存储瓶颈。
　　垂直分库的做法，把一个数据库按照业务拆分成不同的数据库：
　　水平分库分表的做法，把单张表的数据按照一定的规则分布到多个数据库。
　　以上是架构层面的优化，可以用缓存，主从，分库分表
　　第三个环节：
　　解析器，词法和语法分析，主要是保证语句的正确性，语句不出错就没问题。由Sever自己处理，跳过。
　　第四步：优化器四优化器SQL语句分析与优化
　　优化器就是对我们的SQL语句进行分析，生成执行计划。
　　问题是：在我们做项目的时候，有时会收到DBA的邮件，里面列出了我们项目上几个耗时比较长的项目询问语句，让我们去优化，这些语句是从哪里来的呢？
　　我们的服务层每天执行了这么多SQL语句，它怎么知道哪些SQL语句比较慢呢？
　　第一步，我们要把SQL执行情况记录下来。
　　慢查询日志slowquerylog
　　https：dev。mysql。comdocrefman5。7enslowquerylog。html
　　打开慢日志开关
　　因为开启慢查询日志是有代价的（跟binlog、optimizertrace一样），所以它默认是关闭的：showvariableslikeslowquery；
　　除了这个开关，还有一个参数，控制执行超过多长时间的SQL才记录到慢日志，默认是10秒。
　　showvariableslikelongquery；
　　可以直接动态修改参数（重启后失效）。setglobal。slowquerylog1；1开启，0关闭，重启后失效
　　setglobal。longquerytime3；mysql默认的慢查询时间是10秒，另开一个窗口后才会查
　　到最新值
　　showvariableslikelongquery；
　　showvariableslikeslowquery；
　　或者修改配置文件my。cnf。
　　以下配置定义了慢查询日志的开关、慢查询的时间、日志文件的存放路径。slowquerylogON
　　longquerytime2
　　slowquerylogfilevarlibmysqllocalhostslow。log
　　模拟慢查询：
　　selectsleep（10）；
　　查询userinnodb表的500万数据（检查是不是没有索引）。
　　SELECTFROMuserinnodbwherephone136；
　　慢日志分析
　　日志内容showglobalstatuslikeslowqueries；查看有多少慢查询showvariableslikeslowquery；获取慢ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志a目录catvarlibmysqllocalhostslow。log
　　有了慢查询日志，怎么去分析统计呢？比如SQL语句的出现的慢查询次数最多，平均每次执行了多久？人工肉眼分析显然不可能。
　　mysqldumpslowhttps：dev。mysql。comdocrefman5。7enmysqldumpslow。html
　　MySQL提供了mysqldumpslow的工具，在MySQL的bin目录下。mysqldumpslowhelp
　　例如：查询用时最多的10条慢SQL：mysqldumpslowstt10gselectvarlibmysqllocalhostslow。log
　　Count代表这个SQL执行了多少次；
　　Time代表执行的时间，括号里面是累计时间；
　　Lock表示锁定的时间，括号是累计；
　　Rows表示返回的记录数，括号是累计。
　　除了慢查询日志之外，还有一个SHOWPROFILE工具可以使用
　　SHOWPROFILEhttps：dev。mysql。comdocrefman5。7enshowprofile。html
　　SHOWPROFILE谷歌高级架构师JeremyCole贡献给MySQL社区的，可以查看SQL语句执行的时候使用的资源，比如CPU、IO的消耗情况。
　　在SQL中输入helpprofile可以得到详细地帮助信息
　　查看是否开启selectprofiling；setprofiling1；
　　查看profile统计showprofiles；
　　查看最后一个SQL的执行详细信息，从中找出耗时较多的环节（没有s）。showprofile；
　　6。2E5，小数点左移5位，代表0。000062秒。
　　也可以根据ID查看执行详细信息，在后面带上forqueryID。showprofileforquery1；
　　除了慢日志和showprofile，如果要分析出当前数据库中执行的慢的SQL，还可以通过查看运行线程状态和服务器运行信息、存储引擎信息来分析。
　　其他系统命令
　　showprocesslist运行线程https：dev。mysql。comdocrefman5。7enshowprocesslist。htmlshowprocesslist；
　　这是很重要的一个命令，用于显示用户运行线程。可以根据id号kill线程。
　　也可以查表，效果一样：（可以grouporderby了）selectfrominformationschema。processlist；
　　showstatus服务器运行状态
　　说明：https：dev。mysql。comdocrefman5。7enshowstatus。html
　　详细参数：https：dev。mysql。comdocrefman5。7enserverstatusvariables。html
　　SHOWSTATUS用于查看MySQL服务器运行状态（重启后会清空），有session和global两种作
　　用域，格式：参数值。
　　可以用like带通配符过滤。SHOWGLOBALSTATUSLIKEcomselect；查看select次数
　　showengine存储引擎运行信息
　　https：dev。mysql。comdocrefman5。7enshowengine。html
　　https：dev。mysql。comdocrefman5。7eninnodbstandardmonitor。html
　　showengine用来显示存储引擎的当前运行信息，包括事务持有的表锁、行锁信息；事务地锁等待
　　情况；线程信号量等待；文件IO请求；bufferpool统计信息。
　　例如：
　　showengineinnodbstatus；
　　如果需要将监控信息输出到错误信息errorlog中（15秒钟一次），可以开启输出。showvariableslikeinnodbstatusoutput；开启输出：SETGLOBALinnodbstatusoutputON；SETGLOBALinnodbstatusoutputlocksON；
　　我们现在已经知道了这么多分析服务器状态、存储引擎状态、线程运行信息的命令，如果让你去写一个数据库监控系统，你会怎么做？
　　其实很多开源的查询日志监控工具，他们的原理其实也都是读取的系统的变量和状态。
　　现在我们已经知道哪些SQL慢了，为什么慢呢？慢在哪里？
　　MySQL提供了一个执行计划的工具（在架构中我们有讲到，优化器最终生成的就是一个执行计划），其他数据库，例如Oracle也有类似的功能。
　　通过EXPLAIN我们可以模拟优化器执行任务SQL查询语句的过程，才知道MySQL是怎么处理的SQL语句的。通过这种方式我们可以分析语句或者表的性能瓶颈。
　　SHOWGLOBALSTATUSLIKEcomselect；查看select次数showengineinnodbstatus；
　　showvariableslikeinnodbstatusoutput；开启输出：
　　SETGLOBALinnodbstatusoutputON；
　　SETGLOBALinnodbstatusoutputlocksON；
　　MySQL5。6。3以前只能分析SELECT；MySQL5。6。3以后就可以分析update、delete、insert了。
　　EXPLAIN执行计划
　　https：dev。mysql。comdocrefman5。7enexplainoutput。html
　　我们先创建三张表。一张课程表，一张老师表，一张老师联系方式表（没有任何索引）。DROPTABLEIFEXISTScourse；CREATETABLEcourse（cidINT（3）DEFAULTNULL，cnameVARCHAR（20）DEFAULTNULL，tidINT（3）DEFAULTNULL）ENGINEINNODBDEFAULTCHARSETutf8mb4；DROPTABLEIFEXISTSteacher；CREATETABLEteacher（tidINT（3）DEFAULTNULL，tnameVARCHAR（20）DEFAULTNULL，tcidINT（3）DEFAULTNULL）ENGINEINNODBDEFAULTCHARSETutf8mb4；DROPTABLEIFEXISTSteachercontact；CREATETABLEteachercontact（tcidINT（3）DEFAULTNULL，phoneVARCHAR（200）DEFAULTNULL）ENGINEINNODBDEFAULTCHARSETutf8mb4；INSERTINTOcourseVALUES（1，mysql，1）；INSERTINTOcourseVALUES（2，jvm，1）；INSERTINTOcourseVALUES（3，juc，2）；INSERTINTOcourseVALUES（4，spring，3）；INSERTINTOteacherVALUES（1，bobo，1）；INSERTINTOteacherVALUES（2，jim，2）；INSERTINTOteacherexplain的结果有很多的字段，我们详细地分析一下。先确认一下环境：4。3。1idid是查询序列编号。id值不同id值不同的时候，先查询id值大的（先大后小）。查询顺序：coursecteachertteachercontacttc。先查课程表，再查老师表，最后查老师联系方式表。子查询只能以这种方式进行，只有拿到内层的结果之后才能进行外层的查询。id值相同（从上往下）VALUES（3，dahai，3）；INSERTINTOteachercontactVALUES（1，13688888888）；INSERTINTOteachercontactVALUES（2，18166669999）；INSERTINTOteachercontactVALUES（3，17722225555）；
　　explain的结果有很多的字段，我们详细地分析一下。
　　先确认一下环境：selectversion（）；showvariableslikeengine；
　　id
　　id查询序列编号。
　　id值得不同的时候，先查询id值大的（先大后小）。查询mysql课程的老师手机号EXPLAINSELECTtc。phoneFROMteachercontacttcWHEREtcid（SELECTtcidFROMteachertWHEREt。tid（SELECTc。tidFROMcoursecWHEREc。cnamemysql））；
　　查询顺序：coursecteachertteachercontacttc。
　　先查课程表，再查老师表，最后查老师联系方式表。的查询只能以这种方式进行，只有拿到内层的结果果之后才能进行外层的查询。
　　id值相同（从上往下）查询课程ID为2，或者联系表ID为3的老师EXPLAINSELECTt。tname，c。cname，tc。phoneFROMteachert，coursec，teachercontacttcWHEREt。tidc。tidANDt。tcidtc。tcidAND（c。cid2ORtc。tcid3）；
　　id值相同时，表的查询顺序是从上往下顺序执行。例如这次查询的id都是1，查询的顺序是teachert（3条）coursec（4）teachercontacttc（3条）。
　　既有相同也有不同
　　如果ID有相同也有不同，就是ID不同的先大后小，ID相同的是从上往下。
　　4。3。2selecttype查询类型
　　这里并没有列举全部（其它：DEPENDENTUNION、DEPENDENTSUBQUERY、MATERIALIZED、UNCACHEABLESUBQUERY、UNCACHEABLEUNION）。
　　下面列举了一些常见的查询类型：
　　SIMPLE
　　简单查询，不包含子查询，不包含关联查询union。EXPLAINSELECTFROMteacher；
　　再看一个包含子查询的案例：查询mysql课程的老师手机号EXPLAINSELECTtc。phoneFROMteachercontacttcWHEREtcid（SELECTtcidFROMteachertWHEREt。tid（SELECTc。tidFROMcoursecWHEREc。cnamemysql））；
　　PRIMARY
　　的查询SQL语句中的主查询，也就是最外面的那层查询。
　　SUBQUERY
　　的查询中所有的内层查询都是SUBQUERY类型的。
　　DERIVED
　　衍生查询，表示在得到最终查询结果之前会用到临时表。例如：查询ID为1或2的老师教授的课程EXPLAINSELECTcr。cnameFROM（SELECTFROMcourseWHEREtid1UNIONSELECTFROMcourseWHEREtid2）cr；
　　对于关联查询，先执行右边的table（UNION），再执行左边的table，类型是DERIVED
　　UNION
　　用到了UNION查询。同上例。
　　UNIONRESULT
　　主要是显示哪些表之间存在UNION查询。union2，3代表id2和id3的查询存在UNION。同上例。
　　4。3。3type连接类型
　　https：dev。mysql。comdocrefman5。7enexplainoutput。htmlexplainjointypes
　　所有的连接类型中，上面的最好，越往下越差。
　　在常用的链接类型中：systemconsteqrefrefrangeindexall这里并没有列举全部（其他：fulltext、refornull、indexmerger、uniquesubquery、indexsubquery）。
　　以上访问类型除了all，都能用到索引。
　　const
　　主键索引或者唯一索引，只能查到一条数据的SQL。DROPTABLEIFEXISTSsingledata；CREATETABLEsingledata（idINT（3）PRIMARYKEY，contentVARCHAR（20））；INSERTINTOsingledataVALUES（1，a）；EXPLAINSELECTFROMsingledataaWHEREid1；
　　system
　　system是const的一种特例，只有一行满足条件。例如：只有一条数据的系统表。EXPLAINSELECTFROMmysql。proxiespriv；
　　eqref
　　通常出现在多表的join查询，表示对于前表的每一个结果，，都只能匹配到后表的一行结果。一般是唯一性索引的查询（UNIQUE或PRIMARYKEY）。
　　eqref是除const之外最好的访问类型。
　　先删除teacher表中多余的数据，teachercontact有3条数据，teacher表有3条数据。DELETEFROMteacherWHEREtidIN（4，5，6）；COMMIT；备份INSERTINTOteacherVALUES（4，jim，4）；INSERTINTOteacherVALUES（5，bobo，5）；INSERTINTOteacherVALUES（6，seven，6）；COMMIT；
　　为teachercontact表的tcid（第一个字段）创建主键索引。ALTERTABLEteachercontactDROPPRIMARYKEY；ALTERTABLEteachercontactADDPRIMARYKEY（tcid）；
　　为teacher表的tcid（第三个字段）创建普通索引ALTERTABLEteacherDROPINDEXidxtcid；
　　ALTERTABLEteacherADDINDEXidxtcid（tcid）；
　　执行以下SQL语句：selectt。tcidfromteachert，teachercontacttcwheret。tcidtc。tcid；
　　此时的执行计划（teachercontact表示eqref）：
　　小结：
　　以上三种system，const，eqref，都是可遇而不可求的，基本上很难优化到这个状态。
　　ref
　　查询用到了非唯一性索引，或者关联操作只使用了索引的最左前缀。
　　例如：使用tcid上面的普通索引查询：explainSELECTFROMteacherwheretcid3；
　　range
　　索引范围扫描。
　　如果where后面是betweenand或或或或或in这些，type类型就为range。
　　不走索引一定是全表扫描（ALL），所以先加上普通索引。ALTERTABLEteacherDROPINDEXidxtid；ALTERTABLEteacherADDINDEXidxtid（tid）；
　　执行范围查询（字段上有普通索引）：EXPLAINSELECTFROMteachertWHEREt。tid3；或EXPLAINSELECTFROMteachertWHEREtidBETWEEN1AND2；
　　IN查询也是range（字段有主键索引）EXPLAINSELECTFROMteachercontacttWHEREtcidin（1，2，3）；
　　index
　　FullIndexScan，查询全部索引中的数据（比不走索引要快）。EXPLAINSELECTtidFROMteacher；
　　all
　　FullTableScan，如果没有索引或者没有用到索引，type就是ALL。代表全表扫描。
　　小结：
　　一般来说，需要保证查询至少达到range级别，最好能达到ref。
　　ALL（全表扫描）和index（查询全部索引）都是需要优化的。
　　possiblekey、key
　　可能用到的索引和实际用到的索引。如果是NULL就代表没有用到索引。
　　possiblekey可以有一个或者多个，可能用到索引不代表一定用到索引。
　　反过来，possiblekey为空，key可能有值吗？
　　表上创建联合索引：ALTERTABLEuserinnodbDROPINDEXcomidxnamephone；ALTERTABLEuserinnodbaddINDEXcomidxnamephone（name，phone）；
　　执行计划（改成selectname也能用到索引）：explainselectphonefromuserinnodbwherephone126；
　　结论：是有可能的（这里是覆盖索引的情况）。
　　如果通过分析发现没有用到索引，就要检查SQL或者创建索引。
　　keylen
　　索引的长度（使用的字节数）。跟索引字段的类型、长度有关。
　　表上有联合索引：KEYcomidxnamephone（name，phone）explainselectfromuserinnodbwherenamejim；
　　rows
　　MySQL认为扫描多少行才能返回请求的数据，是一个预估值。一般来说行数越少越好。
　　filtered
　　这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，它是
　　一个百分比。
　　ref
　　使用哪个列或者常数和索引一起从表中筛选数据。
　　Extra
　　执行计划给出的额外的信息说明。
　　usingindex
　　用到了覆盖索引，不需要回表。EXPLAINSELECTtidFROMteacher；
　　usingwhere
　　使用了where过滤，表示存储引擎返回的记录并不是所有的都满足查询条件，需要在server层进行过滤（跟是否使用索引没有关系）。EXPLAINselectfromuserinnodbwherephone13866667777；
　　usingfilesort
　　不能使用索引来排序，用到了额外的排序（跟磁盘或文件没有关系）。需要优化。（复合索引的前提）ALTERTABLEuserinnodbDROPINDEXcomidxnamephone；ALTERTABLEuserinnodbaddINDEXcomidxnamephone（name，phone）；EXPLAINselectfromuserinnodbwherenamejimorderbyid；
　　（orderbyid引起）
　　usingtemporary
　　用到了临时表。例如（以下不是全部的情况）：
　　1、distinct非索引列EXPLAINselectDISTINCT（tid）fromteachert；
　　2、groupby非索引列EXPLAINselecttnamefromteachergroupbytname；
　　3、使用join的时候，group任意列3。EXPLAINselectt。tidfromteachertjoincoursecont。tidc。tidgroupbyt。tid；
　　需要优化，例如创建复合索引。
　　总结一下：
　　模拟优化器执行SQL查询语句的过程，才知道MySQL是怎么处理一条SQL语句的。通过这种方式我们可以分析语句或者表达的性能瓶颈。
　　分析出问题之后，就是对SQL语句的具体优化。
　　SQL与索引优化
　　SQL语句的优化的目标，大部分时候都是用到索引。
　　我们在第二节课里面也讲到了索引创建的原则，什么情况会用到索引，什么情况不会用到索引。五、存储引擎
　　存储引擎的选择
　　为不同的业务表选择不同的存储引擎，例如：查询插入操作多的业务表，用MyISAM。临时数据用Memory。常规的并发大更新多的表用InnoDB
　　字段定义
　　原则：使用可以正确存储数据的最小数据类型。
　　为每一列选择合适的字段类型。
　　整数类型
　　TINYINT1个字节SMALLINT2个字节MEDIUMINT3个字节INT，INTEGER4个字节BIGINT8个字节
　　INT有8种类型，不同的类型的最大存储范围是不一样的。
　　性别？用TINYINT，因为ENUM也是整数存储。
　　字符类型
　　变长情况下，varchar更节省空间，但是对于varchar字段，需要一个字节来记录长度。
　　固定长度的用char，不要用varchar。
　　不要用外键、触发器、视图
　　降低了可读性；
　　影响数据库性能，应该把把计算的事情交给程序，数据库专心做存储；
　　数据的完整性应该在程序中检查。
　　大文件存储
　　不要用数据库存储图片（比如base64编码）或者大文件；
　　把文件放在NAS上，数据库只需要存储URI（相对路径），在应用中配置NAS服务器地址。
　　表拆分或字段冗余
　　将不常用的字段拆分出去，避免列数过多和数据量过大。
　　比如在业务系统中，要记录所有接收和发送的消息，这个消息是XML格式的，用blob或者text存
　　储，用来追踪和判断重复，可以建立一张表专门用来存储报文。六总结：优化体系
　　所以，如果在面试的时候再问到这个问题你会从哪些维度来优化数据库，你会怎么回答？
　　除了对于代码、SQL语句、定义、架构、配置优化之外，业务层面的优化也不能忽视。举两个例子：
　　1）在某一年的双十一，为什么会做一个充值到余额宝和余额宝奖金的活动，例如充300送50？因为使用余额或者余额宝付款是记录本地或者内部数据库，而使用银行卡付款，需要调用接口，操内部数据库肯定更快。
　　2）在去年的双十一，为什么在凌晨禁止查询今天之外的账单？
　　这是一种降级措施，用来保证当前最核心的业务。
　　3）最近几年的双十一，为什么提前个把星期就已经有双十一当天的价格了？
　　预售分流。
　　4）公安局的同名查询，不是实时返回结果（不是实时查询数据库），而是通过公众号推送。
　　在应用层面同样有很多其他的方案来优化，达到尽量减轻数据库的压力的目的，比如限流，或者引入MQ削峰，等等等等。
　　为什么同样用MySQL，有的公司可以抗住百万千万级别的并发，而有的公司几百个并发都扛不住，关键在于怎么用。所以，用数据库慢，不代表数据库本身慢，有的时候还要往上层去优化。
　　当然，如果关系型数据库解决不了的问题，我们可能需要用到搜索引擎或者大数据的方案了，并不所有的数据都要放到关系型数据库存储。