(一)、选择Percona Server、MariaDB还是MYSQL
1、Mysql三种存储引擎
MySQL提供了两种存储引擎：MyISAM和 InnoDB，MySQL4和5使用默认的MyISAM存储引擎。从MYSQL5.5开始，MySQL已将默认存储引擎从MyISAM更改为InnoDB。
MyISAM没有提供事务支持，而InnoDB提供了事务支持。
XtraDB是InnoDB存储引擎的增强版本，被设计用来更好的使用更新计算机硬件系统的性能，同时还包含有一些在高性能环境下的新特性。
2、Percona Server分支
Percona Server由领先的MySQL咨询公司Percona发布。
Percona Server是一款独立的数据库产品，其可以完全与MySQL兼容，可以在不更改代码的情况了下将存储引擎更换成XtraDB。是最接近官方MySQL Enterprise发行版的版本。
Percona提供了高性能XtraDB引擎，还提供PXC高可用解决方案，并且附带了percona-toolkit等DBA管理工具箱，
3、MariaDB
MariaDB由MySQL的创始人开发，MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。
MariaDB提供了MySQL提供的标准存储引擎，即MyISAM和InnoDB，10.0.9版起使用XtraDB(名称代号为Aria)来代替MySQL的InnoDB。
4、如何选择
综合多年使用经验和性能对比，首选Percona分支，其次是MariaDB，如果你不想冒一点风险，那就选择MYSQL官方版本。
二、常用的MYSQL调优策略
1、硬件层相关优化
修改服务器BIOS设置
选择Performance Per Watt Optimized(DAPC)模式，发挥CPU最大性能。
Memory Frequency(内存频率)选择Maximum Performance(最佳性能)
内存设置菜单中，启用Node Interleaving，避免NUMA问题
2、磁盘I/O相关
使用SSD硬盘
如果是磁盘阵列存储，建议阵列卡同时配备CACHE及BBU模块，可明显提升IOPS。
raid级别尽量选择raid10，而不是raid5.
3、文件系统层优化
使用deadline/noop这两种I/O调度器，千万别用cfq
使用xfs文件系统，千万别用ext3；ext4勉强可用，但业务量很大的话，则一定要用xfs；
文件系统mount参数中增加：noatime, nodiratime, nobarrier几个选项(nobarrier是xfs文件系统特有的)；
4、内核参数优化
修改vm.swappiness参数，降低swap使用率。RHEL7/centos7以上则慎重设置为0，可能发生OOM
调整vm.dirty_background_ratio、vm.dirty_ratio内核参数，以确保能持续将脏数据刷新到磁盘，避免瞬间I/O写。产生等待。
调整net.ipv4.tcp_tw_recycle、net.ipv4.tcp_tw_reuse都设置为1，减少TIME_WAIT，提高TCP效率。
5、Mysql参数优化建议
建议设置default-storage-engine=InnoDB，强烈建议不要再使用MyISAM引擎。
调整innodb_buffer_pool_size的大小，如果是单实例且绝大多数是InnoDB引擎表的话，可考虑设置为物理内存的50% -70%左右。
设置innodb_file_per_table = 1，使用独立表空间。
调整innodb_data_file_path = ibdata1:1G:autoextend，不要用默认的10M,在高并发场景下，性能会有很大提升。
设置innodb_log_file_size=256M，设置innodb_log_files_in_group=2，基本可以满足大多数应用场景。
调整max_connection(最大连接数)、max_connection_error(最大错误数)设置，根据业务量大小进行设置。
另外，open_files_limit、innodb_open_files、table_open_cache、table_definition_cache可以设置大约为max_connection的10倍左右大小。
key_buffer_size建议调小，32M左右即可，另外建议关闭query cache。
mp_table_size和max_heap_table_size设置不要过大，另外sort_buffer_size、join_buffer_size、read_buffer_size、read_rnd_buffer_size等设置也不要过大。
三、 MYSQL常见的应用架构分享
1、主从复制解决方案
这是MySQL自身提供的一种高可用解决方案，数据同步方法采用的是MySQL replication技术。MySQL replication就是从服务器到主服务器拉取二进制日志文件，然后再将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作，通过这种方式保证数据的一致性。
为了达到更高的可用性，在实际的应用环境中，一般都是采用MySQL replication技术配合高可用集群软件keepalived来实现自动failover，这种方式可以实现95.000%的SLA。
2、MMM/MHA高可用解决方案
MMM提供了MySQL主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。在MMM高可用方案中，典型的应用是双主多从架构，通过MySQL replication技术可以实现两个服务器互为主从，且在任何时候只有一个节点可以被写入，避免了多点写入的数据冲突。同时，当可写的主节点故障时，MMM套件可以立刻监控到，然后将服务自动切换到另一个主节点，继续提供服务，从而实现MySQL的高可用。
3，在这个方案中，处理failover的方式是高可用集群软件Heartbeat，它监控和管理各个节点间连接的网络，并监控集群服务，当节点出现故障或者服务不可用时，自动在其他节点启动集群服务。在数据共享方面，通过SAN(Storage Area Network)存储来共享数据，这种方案可以实现99.990%的SLA。
4、Heartbeat/DRBD高可用解决方案
此方案处理failover的方式上依旧采用Heartbeat，不同的是，在数据共享方面，采用了基于块级别的数据同步软件DRBD来实现。
DRBD是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。和SAN网络不同，它并不共享存储，而是通过服务器之间的网络复制数据。
四、MYSQL经典应用架构
其中：
Dbm157是mysql主，dbm158是mysql主的备机，dbs159/160/161是mysql从。
MySQL写操作一般采用基于heartbeat+DRBD+MySQL搭建高可用集群的方案。通过heartbeat实现对mysql主进行状态监测，而DRBD实现dbm157数据同步到dbm158。
读操作普遍采用基于LVS+Keepalived搭建高可用高扩展集群的方案。前端AS应用通过提高的读VIP连接LVS，LVS有keepliaved做成高可用模式，实现互备。
最后，mysql主的从节点dbs159/160/161通过mysql主从复制功能同步mysql主的数据，通过lvs功能提供给前端AS应用进行读操作，并实现负载均衡。
(二)mysql常用配置的解释。
skip-external-locking 在某些系统中，lockd锁管理器可能不能正常工作，可以使用skip-external-locking告诉mysqld不使用外部锁定。(这意味着你不能在同一个数据目录运行两个mysqld服务器，而且如果你使用相同内存配置，也需要特别注意) 在Mysql4.0版本之后，外部锁定默认是禁用的，而启用外部锁定(系统锁定)，如果系统上的lockd不能完全工作(比如Linux系统)，很容易造成mysqld死锁。 明确的禁用外部锁定，可以通过配置skip-external-locking。 外部锁定只影响存储引擎为MyISAM表的访问。 key_buffer_size = 16M 这个参数的含义是：MyISAM表用于索引块的缓冲区大小，可以被所有线程所共享，默认值是8388608(即8M)，它是对MyISAM表性能影响最大的一个参数，如果数据库存储引擎为InnoDB类型，这个参数是无效的。可以通过增大这个值，以便索引更好的处理所有读和多写操作。 这里有两篇相关的文章值得参阅： mysql优化：Key_buffer_size MySQL的key_buffer_size参数 max_allowed_packet = 1M 表示一个数据包的最大大小，或任何生成的/中间字符串，或任何mysql_stmt_send_long_data() API 函数传递的参数。数据包消息的缓冲区被初始化为net_buffer_length的字节(net_buffer_length默认值为16384：16KB，最大可以设置为1048576：1M)，但是在需要的时候可以增长到max_allowed_packet字节，这个参数的默认值是4M，在接收一些大的数据包时可能会出现错误，最大可以设置为1GB。当你通过修改这个变量的值更改消息缓冲区的大小时，如果客户端程序允许的话，建议在客户端也修改缓冲区的大小。在客户端库，默认的max_allowed_packet是1GB，但是个人的客户端可能会重写这个值，例如，mysql和mysqldump分别是16 MB和24 MB。可以通过在命令行设置或在配置文件中修改max_allowed_packet参数来更改客户端的值，需要注意的是：在session会话级别中，这个变量是只读的。 table_open_cache = 64 表示所有线程打开表的数量，增加该值会增加mysqld要求的文件描述符的数量？你可以通过检查Opened_tables状态变量来确定是否需要增加表缓存数量(Opened_tables表示已打开的表的数量)。如果这个值很大，你又不经常使用FLUSH TABLES(这个命令会强制关闭并重新打开所有表)，可以增加table_open_cache的值。 table_open_cache和max_connections系统变量影响文件服务器保持打开的最大数量。如果你增加了其中一个或两个值，可能会超过操作系统上每个进程打开的文件描述符的数量限制。许多的操作系统允许你增加这个限制，但是也需要确定操作系统是否有可能增加打开文件的限制，以及如何去做。 table_open_cache的值与max_connections的值存在关系。例如，对于200个并发运行的连接，指定table_open_cache的值 至少为200 * N，其中 N是 任何参与 执行 查询的连接中关联 表的最大 数量。你还必须为临时表和文件保留一些额外的文件描述符。 请确保你的操作系统能够处理由table_open_cache设置的隐含打开的文件描述符的数量。如果table_open_cache值设置的太高，MYSQL可能使用完文件描述符而拒绝连接，不能执行查询，并会变的不可靠。还必须需要考虑的是，MyISAM存储引擎中，每个唯一打开的表都需要两个文件描述符。你可以通过在mysqld的启动选项中配置open-files-limit参数，来增加MySQL可用的文件描述符的数量。 sort_buffer_size = 512K 表示为每一个需要排序的会话分配一个指定的缓存区大小。sort_buffer_size的值不特定于任何存储引擎，它适用于对优化的一般方式。通过SHOW GLOBAL STATUS命令，如果你发现每秒钟有许多的Sort_merge_passes输出(Sort_merge_passes表示不得不做合并排序算法的数量)，我们就需要考虑增加sort_buffer_size的值，以加快order by 或 group by 等操作的查询性能(order by和group by的查询效率很难通过优化查询和改善索引提供效率)。 优化器会尝试找出有多少空间是必要的，但可以分配更多，直到达到极限。值得注意的是：如果全局的设置，大于系统所需要的值，将减缓大部分涉及排序的查询效率。最好在session会话级别增加它的值，而且值针对那些需要增加sort_buffer_size的session会话。在Linux系统中，有256KB和2MB的阈值，其中较大的值可能显著减慢内存分配，所以你应该考虑那些较小的值。 net_buffer_length = 8K 每个客户端线程都与一个connection连接缓冲区和结果缓冲区相关联，默认值是16K。两者最初的大小都是net_buffer_length，但是根据需要会动态的扩大到max_allowed_packet设置的大小，结果缓冲区在每一个sql语句执行后都会缩小到设置的net_buffer_length。 这个变量通常不应该改变，但是如果你的系统内存很小，你可以将其设置为客户端语句的期望长度。如果语句的长度超过这个值，connection连接缓冲区会自动的扩大。net_buffer_length参数的最大值可以设置到1M。需要注意的是：在session会话级别中，这个变量是只读的。read_buffer_size = 256K 进行顺序扫描的MyISAM表的 每个线程，都为它扫描的每个表分配一个指定大小的缓冲区。如果需要做很多的顺序扫描，你可能会增大这个值，默认值为131072(128K)。这个变量的值应该是4KB的倍数。如果它被设置为不是4KB的倍数，它的值将被舍入为4KB的最近倍数。 该参数在以下情况时适用于所有的搜索引擎：缓存索引在一个临时文件(而不是临时表)，使用ORDER BY进行行排序时。
进行分区批量插入操作时。
对于嵌套查询缓存结果。
如果使用 另外一个存储引擎，需要为MEMORY表确定内存块大小。 read_buffer_size 最大允许 设置为 2GB 。 read_rnd_buffer_size = 512K 此变量用于多范围读取优化，包括MyISAM表以及任何存储引擎。当从一个有排序操作的MyISAM表的一个关键分拣操作中读取行，该行通过该缓冲区读取，以避免磁盘寻道。设置这个值为较大的值可以显著的提高ORDER BY操作的性能， 然而，这是分配给每一个客户端的缓冲区，所以不应该在全局级别将其设置为一个较大的值。相反，只有在需要进行大量查询操作的客户端才建议在session会话级别增大这个变量值。read_rnd_buffer_size最大允许设置为2GB。 myisam_sort_buffer_size = 8M 表示在REPAIR TABLE上进行MyISAM索引排序时，或通过CREATE INDEX、ALTER TABLE创建索引时，分配的缓冲区大小。相应的，对于InnoDB引擎，有InnoDB_sort_buffer_size的设置。 query_cache_size= 8M 表示分配给高速缓存查询结果的内存量。默认情况下，查询缓存是禁用的。这是通过使用默认的query_cache_size为 1M，query_cache_type为0(为0表示不启用查询缓存)使用的，这样做会显著降低开销，因为如果你设置了query_cache_size为0，你也需要在启动时设置query_cache_type为0。 允许设置的值为1024的倍数，其他设置的值会四舍五入到最近的那个值。 需要 注意的是，即使query_cache_type设置为0，query_cache_size字节的内存也会被默认的分配。 查询缓存需要一个最小大小约40 kb的分配结构(具体的值取决于系统结构)。如果设置的query_cache_size太小，还可能会产生一些问题。 query_cache_type的值有0、1、2三种，0表示不进行任何查询缓存；1表示 缓存所有可缓存的查询结果除了那些以SELECT SQL_NO_CACHE开头的查询；2表示只缓存以SELECT SQL_CACHE开头的查询结果。mysql官方doc建议设置为2。 thread_cache_size = 20 表示服务器将会缓存重用的线程数量，当一个客户端断开连接，如果缓存中线程的数量小于设置的thread_cache_size，那么这个客户端的线程会变放入到缓存中。请求的线程如果可能的话，会从高速缓存中去的线程，当缓存为空时，才会创建新的线程。如果系统中存在许多新的连接的话，增加这个变量值可以提高性能。通常情况下，如果你的代码中很好的做了线程实现，这种性能改进并不显著。然而，如果你的服务器每秒有数百个连接，你通常应该设置thread_cache_size足够高，大多数新连接都会使用缓存的线程。通过比较这个变量与Connections(表示尝试连接到Mysql服务器的数量(无论是否连接成功))和Threads_created(表示处理connection连接所创建的线程的数量)状态变量之间的区别，你可以看到线程缓存的高效。 这个变量的默认值是根据以下公式计算的，封顶为100：8 + (max_connections / 100)，但是在嵌入式服务器(libmysqld)这个变量是没有效果的，在MySQL 5.7.2版本之后，这个参数也不再可见。 log-bin=mysql-bin 表示启用二进制日志记录，服务器记录了所有改变数据语句的二进制日志，用于备份和复制。
binlog_format=mixed 之前 MySQL中事务隔离级别与binlog_format的一点理解中学习，这里不再赘述。
innodb_flush_log_at_trx_commit = 2
这个变量的官方定义是：Controls the balance between strict ACID compliance for commit operations，and higher performance that is possible when commit-related I/O operations are rearranged and done in batches。我自己的理解是用于控制两种关系之间的平衡，这两种关系：提交操作严格的ACID特性，提交相关的IO操作被分批的重新排列和完成时可能带来的高性能。你可以通过修改这个变量的默认值达到更好的性能，但是你可能会在意外崩溃时丢失一秒的事务。默认值为 1 完全符合数据库ACID特性，这个值表示，在每次事务提交的时候，InnoDB日志缓冲区的内容都会被写入到日志文件，并且日志文件会被刷新到磁盘。
如果变量值为0，则表示InnoDB日志缓冲区的内容大约每秒被写入日志文件一次，并且日志文件会被刷新到磁盘。那些日志缓冲区中没有写入的内容会在事务提交的时候被写入日志文件。由于进程调度的问题，每秒的刷新并不能100%保证每一秒都发生。由于刷新磁盘的操作只有大约每秒才发生一次，所以在任何mysqld进程崩溃的时候，你都会丧失一秒的事务。
如果变量值为2，则表示InnoDB日志缓冲区的内容会在事务提交的时候写入到日志文件，并且日志文件会大约每秒刷新一次磁盘。同样的，由于进程调度的问题，每秒的刷新并不能100%保证每一秒都发生。由于刷新磁盘的操作只有大约每秒才发生一次，所以在操作系统崩溃或突然断电的时候，你都会丧失一秒的事务数据。
在MySQL 5.6.6版本中，InnoDB日志刷新频率由变量innodb_flush_log_at_timeout,控制，它允许你将日志刷新频率设置为N秒(默认值是1，可以设置1到2700之间的整数值)，但是任何mysqld进程的崩溃都会清除高达N秒的事务数据。
DDL变化和其他内部InnoDB的活动，则是独立的innodb_flush_log_at_trx_commit设置进行InnoDB日志刷新。
InnoDB的崩溃恢复机制是不管变量innodb_flush_log_at_trx_commit的设置的，事务要么全部应用，要么全部删除。
根据数据库应用设置的持久性和一致性，建议参考如下方式进行InnoDB事务设置：如果启用了二进制日志，设置sync_binlog=1。
总是设置innodb_flush_log_at_trx_commit=1。
这么建议的原因是：许多操作系统和一些磁盘硬件愚弄刷新到磁盘的操作，他们可能会告诉mysqld：刷新操作已经发生，但是事实上并没有发生。然后事务的持久性即使设置为1，也不能得到保证。在最糟糕的情况突然断电甚至会造成InnoDB数据的损坏。在SCSI磁盘控制器或本身加速文件刷新的磁盘上使用电池支持的磁盘缓存，会使操作更安全。你也可以尝试使用Unix命令hdparm禁用磁盘写入缓存的硬件高速缓存，或使用特定的硬件供应商提供的其他一些命令。
sync_binlog
如果这个变量的值大于0，MySQL服务器会在sync_binlog提交组被写入到二进制日志之后，使用fdatasync()命令同步二进制日志到磁盘。默认的sync_binlog变量值为0，表示不同步到磁盘。mysql服务器依赖于操作系统不时的刷新二进制文件的内容，用于任何其他文件。值为1是最安全的选择，因为在崩溃的情况下你最多从二进制日志丢失一个提交组。然而，它也是最慢的选择(除非你你的磁盘具有电池备份缓存，这会使得同步非常快)。
innodb_lock_wait_timeout = 20
表示InnoDB事务从等待获取行锁到放弃的时间长度，默认的值为50秒。一个事务试图获取被另一个InnoDB事务锁定的行所等待的最大时间，超时时会发出以下错误信息： ERROR 1205 (HY000)： Lock wait timeout exceeded； try restarting transaction(锁等待超时，试图重启事务)
当锁等待超时后，当前的语句会回滚(并不是整个事务回滚)。如果需要整个事务都回滚，需要在服务器启动时通过innodb_rollback_on_timeout参数设置。
在高度交互的应用程序或OTLP系统中，为了更好的用户反馈或将更新放入一个队列等待后续处理，你可能会减小该变量值。对于长期运行的后端操作，比如在一个数据仓库中存在大批量的插入或更新操作等待完成时，你可能会增加该值。
innodb_lock_wait_timeout仅适用于InnoDB的行级锁。一个MySQL表锁不会发生在InnoDB，这个参数并不适用于等待表锁。
锁等待超时值不适用于死锁，因为在事务死锁时，InnoDB会立即检测到它们并事务回滚。
innodb_lock_wait_timeout可以在运行时，通过SET GLOBAL或SET SESSION声明进行设置。修改全局的设置需要SUPER权限，并会影响接下来所有连接客户端的操作。任何客户端都可以在SESSION会话级别设置innodb_lock_wait_timeout，它只会影响到该客户端。
至此，线上mysql服务器上的配置文件参数已经全部做了整理，对于这些参数也有了一定的认识和了解，接下来，对于经常使用到的connections变量做一下整理，为接下来与同事讨论mysql的优化及设置做些准备，主要是以下几个connections变量：max_connections
系统变量，它表示最大允许的并发客户端连接数，会影响在服务器上运行的线程数量，默认值是151，增加该值会增加mysqld请求的文件描述符的数量。如果所请求的描述符的数量不可用，服务器会减少max_connections的值。连接拒绝是因为，max_connections的最大值，达到了Connection_errors_max_connections状态变量的增量。 thread_cache_size 变量的默认值就与max_connections有关。max_user_connections
表示允许任何给定的MySQL用户帐户同时连接的最大数目。默认值为0表示不限制。此变量可以在服务器启动时或运行时设置一个全局值。它也有一个只读会话值，表示与当前会话相关联的帐户的有效同时连接的限制值。会话级别的max_user_connections初始化如下：如果用户帐户具有非零的MAX_USER_CONNECTIONS资源限制(帐户的资源限制通过GRANT语句指定)，会话级别的MAX_USER_CONNECTIONS值就设为该限制。
否则的话，会话级别的MAX_USER_CONNECTIONS的值会被设置为全局值。
Connection_errors_max_connections
表示当服务器中连接数达到max_connections的限制后，连接数被拒绝的数量。
Connections
表示尝试连接到mysql服务器的数量，无论成功或失败。
Max_used_connections
从服务器启动开始，已同时被使用的最大连接数。
skip-external-locking作用
在Mysql Linux 的发行版中，默认存在一行skip-external-locking，它表示跳过外部锁定，与之相对，External-locking变量表示启用外 部锁定，用于多线程条件下对MyISAM数据表进行锁定，默认情况下mysql是禁用外部锁定的，在现实生产中，我们的业务环境是单服务器环境，不需要外 部锁定，所以将其禁用。
key_buffer_size 在InnoDB引擎时无效
在 现实的生产环境中，我们曾对业务库进行过升级，虽然我们的业务库使用的是InnoDB引擎，但是其中仍然存在几张遗留的使用MyISAM存储引擎的表，设 置这个参数也是为了提供对于这几张表的访问性能，用于这几张表的索引更好的处理读和多写操作。另外，在之前windows上安装mysql 5.5时，会默认产生几个不同生产环境的my.ini文件，这个参数的配置也参阅了其中的一些配置。
table_open_cache=64 设置是否过小
这个参数的设置最好根据现实生产环境进行设置，在mysql命令行通过show global status like 'open%_tables%'，可以查到两个重要的参数，如下：
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 81 |
| Opened_tables | 88 |
+---------------+-------+
对与大多数的服务器设置，建议参考一下公式：Open_tables / Opened_tables >= 0.85；Open_tables / table_open_cache <= 0.95
但是并不是设置table_open_cache越大越好，因为table_cache加大后，使得mysql对 SQL响应的速度更快了，不可避免的会产生更多的死锁(dead lock)，这样反而使得数据库整个一套操作慢了下来，严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断，找到最适合你维护的库的 table_open_cache值。
myisam_sort_buffer_size参数只对MyISAM引擎有效
在现实的生产环境中，虽然我们的业务库使用的是InnoDB引擎，但有多张业务表使用的是MyIsam引擎，需要这个参数，用于进行表恢复时使用的缓冲区的大小，也是参考了mysql 5.5的配置。
net_buffer_length默认为16K,设置为8K？
这个参数根据客户端connection 语句的长度有关，现实的业务并不繁杂，语句也比较简单，参考mysql 5.5的配置，设置net_buffer_length=8k，不过经过与同事讨论，决定使用默认值16K。
thread_cache_size设置为20的依据
这个参数的设置与max_connections有关，max_connections表示最大允许的并发客户端连接数，会影响在服务器上运行的线程数量，默认值是151，thread_cache_size 的设置，官方doc建议公式：8+(max_connections / 100),这与现实的业务也存在关系，当服务器并发很大时，需要修改max_connections的值以满足业务需要，在我们的现实业务 中，thread_cache_size设置为20较为合适。
innodb_flush_log_at_trx_commit 官方doc建设不要修改默认值
虽然mysql官方doc建议将innodb_flush_log_at_trx_commit设置为1，但在现实的业务中，客户对于业务性能的速度很高，默认为1表示，在每次事务提交的时候，InnoDB日志缓冲区的内容都会被写入到日志文件，并且日志文件会被刷新到磁盘。设置为2减少了刷新磁盘的操作，虽然在突然断点或系统崩溃时可能丢失事务数据，但是在业务允许范围内，相反修改此参数对于业务速度有很大的提升。
read_rnd_buffer_size增加order by查询效率
在What exactly is read_rnd_buffer_size中有了一点理解，其中提到了read_buffer_size，在三个方法优化MySQL数据库查询中大概的了解了这个参数的作用，当一个查询不断地扫描某一个表，MySQL会为它分配一段内存缓冲区。read_buffer_size变 量控制这一缓冲区的大小。如果你认为连续扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。不过貌似这两个参数都是值针对于 MyIsam表的，在mysql安装目录my.ini中看到这样一句注释：Size of the buffer used for doing full table scans of MyISAM tables。对于这个参数的配置还需要再讨论。
1.MySQL数据库主从同步延迟原理。
谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作(mysql5.6版本之前)，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高；slave的Slave_IO_Running线程会到主库取日志，效率会比较高，slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施。DML和DDL的IO操作是随机的，不是顺序的，因此成本会很高，还可能是slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。
2.MySQL数据库主从同步延迟是怎么产生的。
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
3.MySQL数据库主从同步延迟解决方案
最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
4.MySQL数据库主从同步延迟产生的因素。1.网络延迟2. master负载3. slave负载一般的做法是，使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器，只作为备份用，不进行其他任何操作，就能相对最大限度地达到’实时’的要求了
另外，再介绍2个可以减少延迟的参数–slave-net-timeout=seconds参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据slave_net_timeout单位为秒默认设置为3600秒| slave_net_timeout | 3600 –master-connect-retry=seconds参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。master-connect-retry单位为秒默认设置为60秒通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟
8325
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
