千万级别，索引优化，SQL查询优化
这里有我之前写的一篇文章：https://blog.csdn.net/star1210644725/article/details/88615290
分库分表会用到读写分离，因为使用不同的存储引擎，来分别应对读场景和写场景。
那用到读写分离，就一定要用到主从复制，比方说我们需要向一个库里边写数据，另外一个库之读，这就考虑到数据同步的问题。
再谈谈高并发的问题
顾名思义，高并发就是每秒很多的事要去处理。
其实所谓的高并发的解决方案，也就是分散压力。单机的物理瓶颈是无法突破的，就像是磁盘的读写速度，一定是有极限的，就像是CPU的处理能力是有极限的。
那么可行的方案都有什么呢？
利用缓存redis，redis是基于内存的数据库，它有极高的读写速度。
利用消息队列的削峰，异步加载。
读写分离
除此之外就是解决物理极限的问题，既然单机不行，那就多台机器一起去处理。
今天的重头戏：主从复制
概念是这样的，我们想要一个机器写，一个机器读（有需求的话可以一批机器读，一批机器写），那么我们需要保证两个数据库里边的数据是一样的，也就是要保证数据的一致性。那就有了一个问题：数据同步的问题，想让两个数据库数据一致，数据怎么同步呢？
数据同步：
master主库的写操作都会保存一份binlog（二进制日志），主库写数据的操作，在从库回放一下，就能做到同步数据了。
想自己做一遍案例的话推荐一个帖子（具体操作都有，可以跟着来）：https://www.cnblogs.com/clsn/p/8150036.html
主从搭建好以后，再说几个坑：
在从库里边插数据，是一个坑，会导致数据无法同步。
主从复制原理图：
主库的所有写操作都记录在binlog里边去，从库和主库建立好联系以后，就安排一个线程负责监控binlog的动静，binglog发生改变，立马将变化的地方告诉自己的Realylog（中继日志），然后再安排一个进程负责监控中继日志的变化，一旦变化了立马更新自己的数据库内容。
监控的线程是单线程的，这是主从复制演示问题的主要来源。mysql5.7以后可以使用多线程。