MySQL里除了临时表，还有啥别的招数能应付大并发查询呢？

关于MySQL如何应对大并发查询，除了使用临时表，确实还有很多其他非常有效的方法，这些方法的核心思路可以归结为几点：一是尽量让查询变得更快，减少每次查询对数据库造成的压力；二是把压力分散开，别让所有请求都挤在一个地方；三是提前把活儿干好,让查询请求来时能直接拿到结果。

最基础也是最重要的方法就是优化查询语句本身和合理地使用索引，这就像是你要在一个巨大的图书馆里找一本书，如果图书摆放杂乱无章（没有索引），你就得一本一本地翻找，效率极低，但如果有准确的索引卡片（数据库索引），你就能直接定位到书架和层数，瞬间找到想要的书，在高并发场景下，一个写得不好的慢查询，就像是一个人在图书馆里慢吞吞地找书，后面排队的人都会被他堵住，通过使用EXPLAIN命令分析查询执行计划，创建合适的索引（比如覆盖索引，让查询只读索引就能拿到数据，不用再回表），避免全表扫描，是提升并发能力的根本。（来源：MySQL官方文档关于优化查询和索引使用的章节）

利用数据库的读写分离架构，这个思路很好理解，人多力量大，分头干活”，数据库的写操作（增、删、改）相对较少，但比较关键；而读操作（查询）则是海量的，如果所有操作都集中在主数据库（Master）上，主数据库很容易成为瓶颈，读写分离的做法是，设置一个主数据库负责处理写操作，然后挂载多个从数据库（Slave），主数据库会把数据变更同步到从数据库上，这样，所有的大并发查询请求就可以被分发到各个从数据库上去执行，大大减轻了主数据库的压力，这需要应用程序的支持，在代码层面配置好读库和写库的数据源。（来源：常见的数据库架构设计实践，如阿里巴巴《Java开发手册》中提到的数据库规范）

第三，使用缓存技术，这是应对高并发查询的“大杀器”，其核心思想是“用空间换时间”，把那些频繁被查询、但又不太经常变化的数据，提前从数据库里查出来，放在一个读写速度极快的内存存储里（比如Redis或Memcached），当后续再有相同的查询请求来时，应用程序不再去麻烦数据库，而是直接从这个高速缓存中获取结果，返回给用户，这样一来，绝大部分的重复性查询压力就被缓存层吸收掉了，数据库几乎感受不到压力，一个电商网站的商品信息、一个新闻站点的热点文章列表，都非常适合用缓存来应对秒杀、热点事件带来的海量查询。（来源：大规模互联网系统架构常见实践，如Martin Fowler的架构模式论述）

第四，对数据进行分库分表，当单台数据库服务器的存储容量或处理能力达到极限时，这就是一个不得不考虑的方案，分库分表就像是把一个超大型超市拆分成多个专业小店（比如家电城、服装城、生鲜超市），把不同的数据分散到不同的数据库实例或数据表中，分库分表可以按照业务维度进行（垂直分库/分表），比如把用户数据和订单数据存到不同的数据库；也可以按照数据范围或哈希值进行（水平分库/分表），比如把1亿条用户数据平均拆分到10个结构相同的表中，这样做之后，一次全量查询就变成了同时查询10个小表，压力被分散了，分库分表会带来跨库查询、事务处理等复杂性，需要引入中间件等工具来管理，是一把双刃剑。（来源：大型互联网公司解决数据量膨胀的常见方案，如《大型网站技术架构：核心原理与案例分析》一书中的描述）

第五，使用连接池，这虽然不是直接优化查询，但对于高并发至关重要，建立数据库连接是一个比较耗资源的操作，如果每次查询都新建一个连接，用完后马上关闭，在高并发下，创建和销毁连接的开销会非常大，甚至可能耗尽资源，连接池相当于提前创建好一批数据库连接放在那里“待命”，当应用程序需要连接数据库时，直接从池子里取一个现成的来用，用完后不是关闭，而是还回池子里留给下一个请求使用，这样就避免了频繁创建连接的开销，极大地提升了响应速度和处理效率。（来源：各类编程语言中数据库访问框架的通用实践，如Java的Druid、HikariCP连接池文档）

还可以考虑使用MySQL自带的查询缓存功能（注：在MySQL 8.0版本中已被移除），它的原理是，MySQL服务器会缓存SELECT语句的文本以及对应的结果，如果后续有一条完全相同的SELECT语句到来，服务器会先检查查询缓存，如果命中，就直接返回结果而无需再解析、执行查询，但在实际生产环境中，由于失效策略比较严格（表有任何更新，该表的所有查询缓存都会失效），在写操作频繁的场景下效果不佳，反而可能成为负担，虽然新版本移除了，但了解其思想有助于理解缓存的重要性。（来源：MySQL 5.7及更早版本官方文档关于查询缓存的说明）

应对MySQL大并发查询是一个系统工程，需要从SQL优化、索引设计、架构（读写分离、分库分表）、缓存应用（应用层缓存、历史查询缓存）以及资源管理（连接池）等多个层面共同着手,才能取得理想的效果。