MySQL数据库日志企业应用实践及优化
MySQL使用不同的模式记录二进制日志信息，常见的有三种模式。
（1）语句模式
语句（statement-based）模式是MySQL5.6版本默认的模式，简单地说，就是每一条被修改的数据的SQL语句都会记录到master的binlog中。在复制slave库的时候，SQL进程会解析成与原来master端执行过的相同的SQL来再次执行。
该模式的优点是不需要记录细到每一行数据的更改变化，因此，可减少binlog日志量，实际上是减少了很多，节约了磁盘I/O，提高了系统性能。
但该模式同样有一些缺点，由于语句模式记录的是执行的SQL语句，所以，对于某些具有特殊功能的SQL语句来说，就可能会导致无法在从库上正确执行，从而导致主从库数据不一致的问题。
例如，当特殊的函数被执行时，当触发器、存储过程等特殊功能被执行时，而row level模式是基于每一行来记录变化的，所以不会出现类似的问题（更多详情请参考混合模式）。
（2）行级模式
简单地说，行级（row-based）模式就是将数据被修改的每一行的情况记录为一条语句。
优点：在行级模式下，binlog中可以不记录执行的SQL语句的上下文相关信息，仅仅记录哪一条记录被修改了，修改成什么样了即可，所以row level的日志内容会非常清楚地记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题。
缺点：行级模式下，所有的执行语句都将根据修改的行来记录，而这就可能会产生大量的日志内容，例如一条语句修改了100万行，语句模式就用一条语句即可搞定，而行级模式执行之后，日志中记录的就是100万行的修改记录，binlog日志的量可能会大得惊人。
（3）混合模式
混合（mixed-based）模式默认采用语句模式记录日志，在一些特定的情况下会将记录模式切换为行级模式记录，这些特殊情况包含但不限于以下情况。
•当函数中包含UUID()时。
•当表中有自增列（AUTO_INCREMENT）被更新时。
•当执行触发器（trigger）或者存储过程（stored function）等特殊功能时。
•当FOUND_ROWS()、ROW_COUNT()、USER()、CURRENT_USER()、CURRENT_USER等执行时。
8.企业中如何选择二进制日志模式
在互联网公司中，使用MySQL的特殊功能比较少（存储过程、触发器、函数），此时可以选择默认的语句模式。
如果公司较多用到MySQL的特殊功能，如存储过程、触发器、函数等，并且需要做主从复制请首选行级模式，次选mixed模式。
二进制日志的模式配置调整
临时调整命令如下：
MySQL数据库优化
MySQL数据库优化是一项非常重要的工作,而且是一项长期的工作, MySQL优化三分靠配置文件及硬件资源的优化,七分靠SQL语句的优化。
MySQL数据库具体优化包括:配置文件的优化、SQL语句的优化、表结构的优化、索引的优化,而配置的优化包括:系统内核、硬件资源、内存、CPU、 MySQL本身配置文件的优化。
硬件上的优化有两种方式:一种是增加内存和提高磁盘读写速度,进而提高 MySQL数据库的查询、更新的速度;另一种提高 MySQL性能的方式是使用多块磁盘来存数可以从多块磁盘上并行读取数据,进而提高读取数据的速度MySQL参数的优化,内存中会为 MySQL保留部分的缓冲区,这些缓冲区可以提高MySQL.的速度,缓冲区的大小可以在 MySQL的配置文件中进行设置
以下为企业级 MySQL百万量级真实环境配置文件my.cnf的内容,用户可以根据实情况修改,代码如下：
[client]
port=3306
socket =/tmp/mysql. sock
[ mysqld]
mysql
server id= 10
port=3306
socket=/tmp/mysql. sock
datadir =/data/mysql/
old_passwords=1
lower_case_table_names=1
character-set- server=utf8
default- storage-engine=MYISAM
log-bin=bin. log
log-error=error log
pid-file= mysql. pid
long_ query_time=2
slow_query_log=ON
slow_query_log_file=slow.log
binlog_cache_size= 4MB
binlog_format=mixed
max_binlog_cache_size=16MB
max_binlog_size= 1GB
expire_logs_days= 30
ft_min_word_len =4
back_log=512
max_allowed_packet= 64MB
max_connections=4096
max_connect_errors= 100
join_buffer_size= 2MB
read_buffer_size= 2MB
read_rnd_buffer_size=2MB
sort_buffer_size= 2MB
query_cache_size= 64MB
table_open_cache= 10000
thread_cache_size=256
max_heap_table_size= 64MB
tmp_table_size=64MB
thread_stack=192KB
thread_concurrency=24
local-infile=0
skip-show-database
skip-name- resolve
skip-external-locking
connect_timeout=600
interactive_timeout=600
wait_timeout=600
#***MyISAM
key_buffer_size= 512MB
bulk_insert_buffer_size=64MB
myisam_sort_ buffer_size=64MB
myisam_max_sort_file_size=1GB
myisam_repair_threads=1
concurrent_insert= 2
myisam_recover
# *** INNODB
innodb_buffer_pool_size= 64GB
innodb_additional_mem_pool_size= 32MB
innodb_data_file_path=ibdata1:1G; ibdata2: 1G:autoextend
innodb_read_io_threads=8
innodb_write_io_threads =8
innodb_file_per_table= 1
innodb_flush_log_at_trx_commit =2
innodb_lock_wait_timeout=120
innodb_log_buffer_size= 8MB
innodb_log_file_size=256MB
innodb_log_files_in_group =3
innodb_max_dirty_pages_ pct= 90
innodb_thread_concurrency =16
innodb_open_files =10000
# *** innodb_force_recovery =4
# *** Replication Slave
read-only
#skip- slave-start
relay-log= relay. log
log-slave-updates