mysql 时常奔溃，报这个错误！

back_log = 300 #指定 MySQL 可能的连接数量。当 MySQL 主线程在很短的时间内得到非常多的连接请求，该参数就起作用，之后主线程花些时间（尽管很短）检查连接并且启动一个新线程。 #back_log 参数的值指出在 MySQL 暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。

max_connections = 1263 #MySQL 无论如何都会保留一个用于管理员（ SUPER ）登陆的连接，用于管理员连接数据库进行维护操作，即使当前连接数已经达到了 max_connections。 #因此 MySQL 的实际最大可连接数为 max_connections+1 ； #这个参数实际起作用的最大值（实际最大可连接数）为 16384，即该参数最大值不能超过 16384，即使超过也以 16384 为准； #增加 max_connections 参数的值，不会占用太多系统资源。系统资源（ CPU、内存）的占用主要取决于查询的密度、效率等； #该参数设置过小的最明显特征是出现” Too many connections ”错误；

max_connect_errors = 10000 #max_connect_errors 是一个 MySQL 中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。max_connect_errors 的值与性能并无太大关系。

open_files_limit = 65535 #65535 #mysql 打开最大文件数

table_open_cache = 1024 #表描述符缓存大小，可减少文件打开 /关闭次数；

max_allowed_packet = 600M #一个查询语句包的最大尺寸。消息缓冲区被初始化为 net_buffer_length 字节，但是可在需要时增加到 max_allowed_packet 个字节。 #该值太小则会在处理大包时产生错误。如果使用大的 BLOB 列，必须增加该值。 #这个值来限制 server 接受的数据包大小。有时候大的插入和更新会受 max_allowed_packet 参数限制，导致写入或者更新失败。

binlog_cache_size = 1M #二进制日志缓冲大小 #我们知道 InnoDB 存储引擎是支持事务的，实现事务需要依赖于日志技术，为了性能，日志编码采用二进制格式。那么，我们如何记日志呢？有日志的时候，就直接写磁盘？ #可是磁盘的效率是很低的，如果你用过 Nginx，，一般 Nginx 输出 access log 都是要缓冲输出的。因此，记录二进制日志的时候，我们是否也需要考虑 Cache 呢？ #答案是肯定的，但是 Cache 不是直接持久化，于是面临安全性的问题——因为系统宕机时，Cache 中可能有残余的数据没来得及写入磁盘。因此，Cache 要权衡，要恰到好处： #既减少磁盘 I/O，满足性能要求；又保证 Cache 无残留，及时持久化，满足安全要求。

max_heap_table_size = 8M #独立的内存表所允许的最大容量. # 此选项为了防止意外创建一个超大的内存表导致永尽所有的内存资源. tmp_table_size = 128M #128M #它规定了内部内存临时表的最大值，每个线程都要分配。（实际起限制作用的是 tmp_table_size 和 max_heap_table_size 的最小值。） #如果内存临时表超出了限制，MySQL 就会自动地把它转化为基于磁盘的 MyISAM 表，存储在指定的 tmpdir 目录下

read_buffer_size = 2M #2M #是 MySQL 读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySQL 会为它分配一段内存缓冲区。read_buffer_size 变量控制这一缓冲区的大小。 #如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。

read_rnd_buffer_size = 8M #8M #是 MySQL 的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySQL 会首先扫描一遍该缓冲，以避免磁盘搜索， #提高查询速度，如果需要排序大量数据，可适当调高该值。但 MySQL 会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。

sort_buffer_size = 8M #是 MySQL 执行排序使用的缓冲大小。如果想要增加 ORDER BY 的速度，首先看是否可以让 MySQL 使用索引而不是额外的排序阶段。 #如果不能，可以尝试增加 sort_buffer_size 变量的大小

join_buffer_size = 8M #8M #应用程序经常会出现一些两表（或多表） Join 的操作需求，MySQL 在完成某些 Join 需求的时候（ all/index join ），为了减少参与 Join 的“被驱动表”的 #读取次数以提高性能，需要使用到 Join Buffer 来协助完成 Join 操作。当 Join Buffer 太小，MySQL 不会将该 Buffer 存入磁盘文件， #而是先将 Join Buffer 中的结果集与需要 Join 的表进行 Join 操作， #然后清空 Join Buffer 中的数据，继续将剩余的结果集写入此 Buffer 中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加 IO 访问，降低效率。

key_buffer_size = 256M #key_buffer_size = 256M #索引块的缓冲区大小，对 MyISAM 表性能影响最大的一个参数.决定索引处理的速度，尤其是索引读的速度。默认值是 16M，通过检查状态值 Key_read_requests #和 Key_reads，可以知道 key_buffer_size 设置是否合理

thread_cache_size = 64 #64 #thread_cahe_size 线程池，线程缓存。用来缓存空闲的线程，以至于不被销毁，如果线程缓存在的空闲线程，需要重新建立新连接， #则会优先调用线程池中的缓存，很快就能响应连接请求。每建立一个连接，都需要一个线程与之匹配。

query_cache_type = 1 #决定是否缓存查询结果。这个变量有三个取值：0,1,2，分别代表了 off、on、demand。

query_cache_size = 64M #64M #工作原理：一个 SELECT 查询在 DB 中工作后，DB 会把该语句缓存下来，当同样的一个 SQL 再次来到 DB 里调用时，DB 在该表没发生变化的情况下把结果从缓存中返回给 Client。 #在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。 query_cache_limit = 2M

ft_min_word_len = 4

log_bin = mysql-bin binlog_format = mixed #在复制方面的改进就是引进了新的复制技术：基于行的复制。简言之，这种新技术就是关注表中发生变化的记录，而非以前的照抄 binlog 模式。 #从 MySQL 5.1.12 开始，可以用以下三种模式来实现：基于 SQL 语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)， #混合模式复制(mixed-based replication, MBR)。相应地，binlog 的格式也有三种：STATEMENT，ROW，MIXED。MBR 模式中，SBR 模式是默认的。

expire_logs_days = 7 #二进制日志自动删除的天数。默认值为 0,表示“没有自动删除”。启动时和二进制日志循环时可能删除。 log_error = /data/mysql/mysql-error.log slow_query_log = 1 #开启慢查询 #slow_query_log_file = /data/mysql/mysql-slow.log

long_query_time = 1 #超过的时间为 1s ； MySQL 能够记录执行时间超过参数 long_query_time 设置值的 SQL 语句，默认是不记录的。

performance_schema = 0 explicit_defaults_for_timestamp

#lower_case_table_names = 1

skip-external-locking

default_storage_engine = InnoDB innodb_file_per_table = 1 innodb_open_files = 500 #500 #限制 Innodb 能打开的表的数量

innodb_buffer_pool_size = 128M #InnoDB 用来高速缓冲数据和索引内存缓冲大小。更大的设置可以使访问数据时减少磁盘 I/O。

innodb_write_io_threads = 4 innodb_read_io_threads = 4 #对于多核的 CPU 机器，可以修改 innodb_read_io_threads 和 innodb_write_io_threads 来增加 IO 线程，来充分利用多核的性能

innodb_thread_concurrency = 0 #分析日志后发现，数据库无法重启的原因是因为 ibdata1 文件损坏，重启后无法正常恢复。 #解决办法： #需要跳过恢复步骤，修改 my.cnf 文件，在 my.cnf 中的[mysqld]中添加：innodb_force_recovery = 6 #innodb_force_recovery = 6

innodb_purge_threads = 1 #开始碎片回收线程。这个应该能让碎片回收得更及时而且不影响其他线程的操作

innodb_flush_log_at_trx_commit = 2 #每次 commit 日志缓存中的数据刷到磁盘中。通常设置为 1，意味着在事务提交前日志已被写入磁盘，事务可以运行更长以及服务崩溃后的修复能力。 #如果你愿意减弱这个安全，或你运行的是比较小的事务处理，可以将它设置为 0，以减少写日志文件的磁盘 I/O。这个选项默认设置为 0。

innodb_log_buffer_size = 2M #InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交(commit)。 #因此，如果有大的事务处理，设置大的日志缓冲可以减少磁盘 I/O。

innodb_log_file_size = 8M #32M #日志组中的每个日志文件的大小(单位 MB)。如果 n 是日志组中日志文件的数目，那么理想的数值为 1M 至下面设置的缓冲池(buffer pool)大小的 1/n。 #较大的值，可以减少刷新缓冲池的次数，从而减少磁盘 I/O。但是大的日志文件意味着在崩溃时需要更长的时间来恢复数据。

innodb_log_files_in_group = 3 #指定有三个日志组 innodb_max_dirty_pages_pct = 60 #90 #innodb_max_dirty_pages_pct 作用：控制 Innodb 的脏页在缓冲中在那个百分比之下，值在范围 1-100,默认为 90.这个参数的另一个用处： #当 Innodb 的内存分配过大，致使 swap 占用严重时，可以适当的减小调整这个值，使达到 swap 空间释放出来。建义：这个值最大在 90%，最小在 15%。 #太大，缓存中每次更新需要致换数据页太多，太小，放的数据页太小，更新操作太慢。

innodb_lock_wait_timeout = 120 #在回滚(rooled back)之前，InnoDB 事务将等待超时的时间(单位秒)

bulk_insert_buffer_size = 16M #8M #默认 8M，当对 MyISAM 非空表执行 insert … select/ insert … values(…),(…)或者 load data infile 时，使用树状 cache 缓存数据，每个 thread 分配一个； #注：当对 MyISAM 表 load 大文件时，调大 bulk_insert_buffer_size/myisam_sort_buffer_size/key_buffer_size 会极大提升速度 myisam_sort_buffer_size = 128M #64M #当对 MyISAM 表执行 repair table 或创建索引时，用以缓存排序索引；设置太小时可能会遇到” myisam_sort_buffer_size is too small ” myisam_max_sort_file_size = 10G myisam_repair_threads = 1

interactive_timeout = 28800 #interactive_time -- 指的是 mysql 在关闭一个交互的连接之前所要等待的秒数(交互连接如 mysql gui tool 中的连接 wait_timeout = 28800 #wait_timeout -- 指的是 MySQL 在关闭一个非交互的连接之前所要等待的秒数

[mysqldump] quick max_allowed_packet = 500M

[myisamchk] key_buffer_size = 256M sort_buffer_size = 8M read_buffer = 4M write_buffer = 4M

目前尚无回复

MySQL 日志磁盘 join