explain
SELECT * FROM nok.msg a where
exists(
select a.user_uid from nok.user_user_friend_ref b where a.user_uid = b.refUser_uid and b.user_uid = 21 and a.authType = 1)
or (a.authType = 4 and a.user_uid = 21)
or exists(
select a.user_uid from nok.authgroup c
inner join nok.user_group_friend_ref d on c.uid = d.group_uid
inner join nok.msg_group_auth_ref e on e.group_uid = c.uid
where a.uid = e.msg_uid and d.user_uid = 21 and a.authType = 3)
or a.uid in(2);
mysql.ini:
max_connect_errors =100000 #max_connect_errors默认值为10，也即mysqld线程没重新启动过，一台物理服务器只要连接 异常中断累计超过10次，就再也无法连接上mysqld服务，为此建议大家设置此值至少大于等于10W
interactive_timeout = 172800 #处于交互状态连接的活动被服务器端强制关闭，而等待的时间，单位：秒；
wait_timeout = 172800 # 与服务器端无交互状态的连接，直到被服务器端强制关闭而等待的时间，此参数只对基于TCP/IP或基于 Socket通信协议建立的连接才有效，单位：秒；
transaction-isolation = repeatabled-read # 事务机制
binlog-format = mixed # 复制的模式，可供设置的值：STATEMENT、ROW、MIXED
innodb_adaptive_hash_index = ON #InnoDB引擎会根据数据的访问频繁度，把表的数据逐渐缓到内存，若是一张表的数据大量缓存在 内存中，则使用散列索引（注：Hash Index）会更高效。
innodb_max_dirty_pages_pct = 70 # InnoDB主线程直接更新Innodb_buffer_pool_size中存在的数据，并且不实时刷回磁盘，而是等待 相关的处罚事件发生，则允许缓存空间的数据量不实时刷回磁盘的最大百分比。比例设置较小，有利于 减少mysqld服务出现问题的时候恢复时间，缺点则是需要更多的物理I/O，为此我们必须根据业务特点 和可承受范围进行一个折中，一般范围建议设置为5%~90%，像我们SNS游戏行业的写非常厉害，综合 各方面因素，设置为20%；
innodb_concurrency_tickets = ？
含义：
同一时刻，能访问InnoDB引擎数据的线程数，默认值为500，范围1-4294967295。
补充说明：当访问InnoDB引擎数据的线程数达到设置的上线，线程将会被放到队列中，等待其他线程释放ticket。
建议：
MySQL数据库服务最大线程连接数参数max_connections，一般情况下都会设置在128-1024的范围，再结合实际业务可能的最大事务并发度，innodb_concurrency_tickets保持默认值一般情况下足够。
innodb_fast_shutdown = 1 #若是机房条件较好可设置为0（双路电源、UPS、RAID卡电池和供电系统稳定性）
innodb_force_recovery =0 #至于出问题的时候，设置为何值，要视出错的原因和程度，对数据后续做的操作
innodb_additional_mem_pool_size = 8M
innodb_buffer_pool_size
提示：
innodb_buffer_pool_size的值设置合适，会节约访问表对象中数据的物理IO。官方手册上建议专用的数据库服务器，可考虑设置为物理内存总量的80%，但是个人建议要看物理服务器的物理内存总量，以及考虑： 是否只使用InnoDB引擎、mysqld内部管理占用的内存、最大线程连接数和临时表等因素，官方提供的80%值作为一个参考，举而个例子方便大家作决定（前提：物理服务器为mysqld服务专用，且只用InnoDB引擎,假设数据量远大于物理内存）：
1).内存配置：24G 则 innodb_buffer_pool_size=18G
1).内存配置：32G 则 innodb_buffer_pool_size=24G
innodb_flush_log_at_trx_commit = N：
N=0 – 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上；
N=1 – 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上；
N=2 – 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件，但不一定刷新到磁盘上，而是取决于操作系统的调度；
sync_binlog = N：
N>0 — 每向二进制日志文件写入N条SQL或N个事务后，则把二进制日志文件的数据刷新到磁盘上；
N=0 — 不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定；
推荐配置组合：
N=1,1 — 适合数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如充值消费系统；
N=1,0 — 适合数据安全性要求高，磁盘IO写能力支持业务不富余，允许备库落后或无复制；
N=2,0或2,m(0<m<100) — 适合数据安全性有要求，允许丢失一点事务日志，复制架构的延迟也能接受；
N=0,0 — 磁盘IO写能力有限，无复制或允许复制延迟稍微长点能接受，例如：日志性登记业务；
innodb_file_per_table = 1
启用单表空间，减少共享表空间维护成本，减少空闲磁盘空间释放的压力。另外，大数据量情况下 的性能，也会有性能上的提升，为此建议大家使用独立表空间 代替 共享表空间的方式；
key_buffer_size
key_buffer_size只能缓存MyISAM或类MyISAM引擎的索引数据，而innodb_buffer_pool_size不仅能缓存索引数据，还能缓存元数据，但是对于我们只使用InnoDB引擎的数据库系统而言，此参数值也不能设置过于偏小，因为临时表可能会使用到此键缓存区空间，索引缓存区推荐：64M；
SELECT FROM_UNIXTIME(1379414306, '%Y-%m-%d %H:%i:%S')
Select UNIX_TIMESTAMP('2013-09-17 19:38:26');
Select UNIX_TIMESTAMP('2013-09-17');
SELECT u.uid ,
CASE WHEN u.creationTime >= UNIX_TIMESTAMP(Adddate( date_format(now(),'%y-%m-%d'),-1 )) THEN 1
ELSE 0 END as rate
FROM nok.user as u ;
select Adddate( date_format(now(),'%y-%m-%d'),-1 );
Select UNIX_TIMESTAMP(Adddate( date_format(now(),'%y-%m-%d'),-1 ));
SELECT FROM_UNIXTIME(1394290800, '%Y-%m-%d %H:%i:%S');
最終更新：2014年03月10日 16:19
