限制，而不是纵容
mysql使用过程中遇到 Too many connections错误的时候，很多dba或者sa第一步操作是 增大 max_connections 参数，尝试恢复服务； 第二步操作是找出罪魁祸首，检查一下究竟是哪个用户（应用）创建了太多的连接，然后再由该应用的RD去检查自己的程序。
能够做到这二点，在很多公司里面已经足够了，dba体现了自己的技术实力，直接解决了问题或者推进了问题的解决，同时表示自己不是整天没有事情做的。
可是，你要清楚，资源并非无限制的，随着connections数量的增加，资源的消耗（内存，CPU等）也会增加。 根本的解决办法应该是限制，而不是纵容。
比如某公司的dba，限制mysql中每个用户的并发连接数为400。如果RD觉得400还是不够用，不好意思，你先优化程序去吧，要么就别用mysql服务了。
…
[获取更多]mysql set and show system variables
mysql中的system variables的作用域有两种：global与session。
set system variables的操作比较简单：
SET GLOBAL sort_buffer_size=1000000; SET SESSION sort_buffer_size=1000000; |
show system variables 与set操作类似，也分为global与session，不多举例。
Global与Session看起来是二种作用域，但是从system
variables是否支持global与session的角度来讲， 又可以分为三种情况:
1) 只支持global。
2) 同时支持global与session。
3) 只支持session。
最容易使人困惑的就是第二种情况了，经常可以遇到以下的情况：
SET GLOBAL xxxx=1; 然后 SHOW VARIABLES LIKE 'xxxx'; 会发现xxxx的值没有发生变化.... |
…
[获取更多]MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ，用于衡量主备之间的复制延迟，但是 今天碰到了一个场景，发现 Seconds_Behind_Master 为 0 ， 备库的 show slave status 显示 IO/SQL 线程都是正常的 ， MySQL 的主库上的变更却长时间无法同步到备库上。如果没有人为干预，直到一个小时以后， MySQL 才会自动重连主库，继续复制主库的变更。
影响范围： MySQL ， Percona ， MariaDB 的所有版本。
虽然这种场景非常特殊，遇到的概率并不高，但是个人觉得有必要提醒一下使用 MySQL 的 DBA 们。通过对这个场景的分析，也有助于我们更加深入的理解 MySQL replication 重试机制。
一、重现步骤
搭建主备的复制，临时断开主库的网络，并 kill 掉主库 MySQL 的 binlog dump 线程。
此时观察备库的复制情况， show slave status 中： …
[获取更多]
MySQL中对于表上ID自增列可以在创建表的时候来指定列上的auto_increment属性；等同于SQL
server中的identity属性；Oracle则是通过Sequence方式来实现。
【mysql】 【系统环境】 【session】 【variables】 点击查看原文>