MySQL的SQL语句或SQL文件经常看到如下用户：
SELECT /*!40001 SQL_CACHE */ * FROM pre_common_syscache WHERE cname IN ('ipbanned')
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
请问其中/*!代码 ……*/代表什么意思？
还有相关变量
变量：query_cache _type，查询缓存的操作模式。有3中模式，0：不缓存；1：缓存查询，除非 与 select sql_no_cache开头；2：根据需要只缓存那些以select sql_cache开头的查 询； query_cache_size：设置查询缓存的最大结果集的大小，比这个值大的不会被缓存。
1.8.4. MySQL对标准SQL的扩展
MySQL服务器包含一些其他SQL DBMS中不具备的扩展。注意，如果使用了它们，将无法把代码移植到其他SQL服务器。在某些情况下，你可以编写包 含MySQL扩展的代码，但仍保持其可移植性，方法是用“/*... */”注释掉这些扩展。在本例中，MySQL服务器能够解析并执行注释中的代码，就 像对待其他MySQL语句一样，但其他SQL服务器将忽略这些扩展。例如：
SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...
如果在字符“!”后添加了版本号，仅当MySQL的版本等于或高于指定的版本号时才会执行注释中的语法：
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
这意味着，如果你的版本号为3.23.02或更高，MySQL服务器将使用TEMPORARY关键字。
装mysql并 运行一段时间后，在mysql目录下出现一堆类似mysql-bin.000***，从mysql-bin.000001开始一直排列下来，而且占用了大 量硬盘空间，高达十几个G.。原来mysql-bin.000001、mysql-bin.000002等文件是数据库的操作日志，例如UPDATE一个表，或者DELETE一些数据，即使该语句没有匹配的数据，这个命令也会存储到日志文件中，还包括每个语句执行的时间，也会记录进去的。 这些形如mysql-bin.00001的文件主要是用来做什么的呢? 1、数据恢复
如果你的数据库出问题了，而你之前有过备份，那么可以看日志文件，找出是哪个命令导致你的数据库出问题了，想办法挽回损失。
2、主从服务器之间同步数据
主服务器上所有的操作都在记录日志中，从服务器可以根据该日志来进行，以确保两个同步。
3、清除办法
运行 /usr/local/mysql/bin/mysql -u root -p 登录执行：
reset master;
如果你只有一个mysql服务器，在/etc/ 下面找到my.cnf文件vim /etc/my.cnf把里面的
#log-bin=mysql-bin #binlog_format=mixed 这两行注释掉，然后将mysql下的var目录中的这些日志文件全部删除，重启mysql服务即可。
但是如果你设置了主从服务器，那么就需要做以下操作了。
A：在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志
。
下面是一些对此类日志处理的mysql命令：
查找当前有哪些二进制日志文件
-
mysql> show binary logs; -
+------------------+-----------+ -
| Log_name | File_size | -
+------------------+-----------+ -
| mysql-bin.000001 | 1357315 | -
| mysql-bin.000002 | 117 | -
| mysql-bin.000003 | 404002 | -
| mysql-bin.000004 | 2050722 | -
| mysql-bin.000005 | 139103 | -
| mysql-bin.000006 | 46702 | -
| mysql-bin.000007 | 117 | -
…………
删除bin-log(删除mysql-bin.000018之前的所有二进制日志文件)
-
mysql
>
purge
binary logs
to
'mysql-bin.000018'
;
-
Query OK
,
0 rows affected
(
0.08 sec
)
其实，bin-log文件主要用于几台服务器之间的数据库同步，如果只有一台服务器并且不考虑同步的话，可以把这个功能禁用掉。但是，很多时候这一 类的日志文件还是很有用的，比如说你不记得做了什么把数据弄丢了，这时这些操作日志就可以帮到你了，所以保留一段时间的日志是很有必要的。可以在/etc /mysql/my.cnf文件里这样设置：
-
log-bin
-
expire_logs_days = 30
B：使用SHOW MASTER LOGS获得主服务器上的一系列日志。
C：在所有的从属服务器中判定最早的日志，这个是目标日志，如果所有的从属服务器是更新的，就是清单上的最后一个日志。
D：清理所有的日志，但是不包括目标日志，因为从服务器还要跟它同步。 简单地说,这些MySQL目录下的形如mysql-bin.000***的文件时MySQL的事务日志。 删除复制服务器已经拿走的binlog是安全的，一般来说网络状况好的时候，保留最新的那一个足以。
在Linux VPS系统上有时候会发现MySQL占用CPU高，导致系统的负载比较高。这种情况很可能是某个SQL语句执行的时间太长导致的。优化一下这个SQL语句或者优化一下这个SQL引用的某个表的索引一般能解决问题。
但是怎么找到是哪个SQL语句的执行时间过长呢？可以通过MySQL Slow Log来找，详解如下。
首先找到MySQL的配置文件my.cnf，根据不同版本的mysql开启慢查询的配置也不一样
mysql 5.0
[mysqld]
long_query_time = 1
log-slow-queries = /var/log/mysql/slow.log
mysql 5.1
[mysqld]
long_query_time = 1
slow_query_log=1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time 是指执行超过多久的sql会被log下来，这里是1秒。
log-slow-queries和slow_query_log_file 设置把日志写在哪里
把上述参数打开，运行一段时间，就可以关掉了，省得影响生产环境
接下来就是分析了，我这里的文件名字叫 /var/log/mysql/slow.log。
先mysqldumpslow –help下，主要用的是
-s ORDER what to sort by (t, at, l, al, r, ar etc), ‘at’ is default
-t NUM just show the top n queries
-g PATTERN grep: only consider stmts that include this string
-s，是order的顺序，说明写的不够详细，主要有
c,t,l,r和ac,at,al,ar，分别是按照query次数，时间，lock的时间和返回的记录数来排序，前面加了a的时倒序
-t，是top n的意思，即为返回前面多少条的数据
-g，后边可以写一个正则匹配模式，大小写不敏感的
mysqldumpslow -s c -t 20 /var/log/mysql/slow.log
mysqldumpslow -s r -t 20 /var/log/mysql/slow.log
上述命令可以看出访问次数最多的20个sql语句和返回记录集最多的20个sql。
mysqldumpslow -t 10 -s t -g “left join” /var/log/mysql/slow.log
这个是按照时间返回前10条里面含有左连接的sql语句。
用了这个工具就可以查询出来那些sql语句是性能的瓶颈，进行优化，比如加索引，该应用的实现方式等。
转载于:https://blog.51cto.com/petermis/1158284
1552
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
