索引之MYSQL
https://www.cnblogs.com/12345huangchun/p/10110809.html
MYSQL之索引原理
一、索引原理
1，什么是索引？
索引在MySQL中也叫‘鍵’或者‘key’，是存儲引擎用於快速找到記錄的一種數據結構。索引對於良好的性能非常關鍵，尤其是當表中的數據量越來越大時，索引對於性能的影響愈發重要，減少IO次數，加快查詢。
2，索引的數據結構：b+樹
上圖就是一個b+樹的數據結構，我們的InnoDB索引的數據就是以這種結構存放的。比如說我們要查找29，首先會把磁盤塊1加載到內存，發生一次IO，發現29在17和35 中間，就鎖定磁盤塊中的p2指向的磁盤模塊3，然后把磁盤塊3加載到內存，發生第二次IO，發現29在26和30之間，就鎖定磁盤塊3中p2指向的磁盤塊8，然后把磁盤塊8加載到內存，發生第三次IO，此時和29相比，有一值等於29，從而就找到了29。這樣的b+樹可以表示上百萬的數據，如果上百萬的數據查找也只需要三次IO，那么性能提高是非常大的，如果沒有索引，每次數據項都要發生一次IO，總共需要上百萬次的IO，得花多少時間。
3，b+樹的性質
3.1 索引字段要盡量的小
通過上面的例子來看，基本上是b+樹的層級高度決定了IO的次數，也決定了查詢的效率，所以，要提高效率就應該減少b+樹的高度。對於每個磁盤塊所能存放的數據量是有限的。假設當前的所有數據大小為N，每個磁盤能存放某個數據的個數為m=磁盤塊的大小/每個數據的大小，則高度為h=log（m+1）N，當數據一定時，m越大，h就越小。說明每個數據越小，高度越低，IO次數就越少，效率就更高。所以我們在建立索引的時候喜歡用id字段，而不是name字段，數字類型肯定比char類型占的空間小嘛。
3.2 索引的最左匹配原則特性
查詢數據是從數據塊的左邊開始匹配，再匹配右邊的。
二、聚集索引與輔助索引
數據庫中的b+樹索引可以分為聚集索引和輔助索引
相同點：其內部都是b+樹的形式，葉子節點都存放着數據
不同點：聚集索引存放的是一整行所有數據，而輔助索引只存放索引字段的數據+主鍵
1，聚集索引
復制代碼
InnoDB存儲引擎表示索引組織表，即表中數據按照主鍵順序存放。而聚集索引（clustered index）就是按照每張表的主鍵構造一棵B+樹，同時葉子結點存放的即為整張表的行記錄數據，也將聚集索引的葉子結點稱為數據頁。聚集索引的這個特性決定了索引組織表中數據也是索引的一部分。
同B+樹數據結構一樣，每個數據頁都通過一個雙向鏈表來進行鏈接。
如果未定義主鍵，MySQL取第一個唯一索引（unique）而且只含非空列（NOT NULL）作為主鍵，InnoDB使用它作為聚簇索引。
如果沒有這樣的列，InnoDB就自己產生一個這樣的ID值，它有六個字節，而且是隱藏的，使其作為聚簇索引。
由於實際的數據頁只能按照一棵B+樹進行排序，因此每張表只能擁有一個聚集索引。在多少情況下，查詢優化器傾向於采用聚集索引。因為聚集索引能夠在B+樹索引的葉子節點上直接找到數據。此外由於定義了數據的邏輯順序，聚集索引能夠特別快地訪問針對范圍值得查詢。
復制代碼
它對主鍵的排序和范圍查找熟讀非常的快，葉子節點的數據就是用戶所要查詢的數據，如用戶需要查找一張表，查詢最后的10位用戶信息，由於b+樹索引是雙向鏈表，所以用戶可以快速查找到最后一個數據夜，並取出10條數據。
復制代碼
參照第六小結測試索引的准備階段來創建出表s1
mysql> desc s1; #最開始沒有主鍵
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| id | int(11) | NO | | NULL | |
| name | varchar(20) | YES | | NULL | |
| gender | char(6) | YES | | NULL | |
| email | varchar(50) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
rows in set (0.00 sec)
mysql> explain select * from s1 order by id desc limit 10; #Using filesort，需要二次排序
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+----------------+
| 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 2633472 | 100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+----------------+
row in set, 1 warning (0.11 sec)
mysql> alter table s1 add primary key(id); #添加主鍵
Query OK, 0 rows affected (13.37 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> explain select * from s1 order by id desc limit 10; #基於主鍵的聚集索引在創建完畢后就已經完成了排序，無需二次排序
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------+
| 1 | SIMPLE | s1 | NULL | index | NULL | PRIMARY | 4 | NULL | 10 | 100.00 | NULL |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------+
row in set, 1 warning (0.04 sec)
復制代碼
范圍查找，即如果查找主鍵某一范圍內的數據，通過葉子節點的上層中間節點就可以得到頁的范圍，之后直接讀取數據既可。
復制代碼
mysql> alter table s1 drop primary key;
Query OK, 2699998 rows affected (24.23 sec)
Records: 2699998 Duplicates: 0 Warnings: 0
mysql> desc s1;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| id | int(11) | NO | | NULL | |
| name | varchar(20) | YES | | NULL | |
| gender | char(6) | YES | | NULL | |
| email | varchar(50) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
rows in set (0.12 sec)
mysql> explain select * from s1 where id > 1 and id < 1000000; #沒有聚集索引，預估需要檢索的rows數如下，explain就是預估一下你的sql的執行效率
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 2690100 | 11.11 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
row in set, 1 warning (0.00 sec)
mysql> alter table s1 add primary key(id);
Query OK, 0 rows affected (16.25 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> explain select * from s1 where id > 1 and id < 1000000; #有聚集索引，預估需要檢索的rows數如下
+----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
| 1 | SIMPLE | s1 | NULL | range | PRIMARY | PRIMARY | 4 | NULL | 1343355 | 100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
row in set, 1 warning (0.09 sec)
2，輔助索引
當我們把id作為主鍵，但我們查找的時候，並不是以id為條件，而寫的是where name=‘dd’時，就沒法用到主鍵索引，此時查找的效率就會很慢，從而我們就需要引入輔助索引，給name添加一個輔助索引。
聚集索引的葉子節點上存放的是一整行的數據，但輔助索引就不是，它的葉子節點只存放了對應字段的數據加上主鍵。如果我們用輔助索引拿到對應字段的數據，如select name from t1 where name=‘kk’這種我們稱為覆蓋索引。如果通過輔助索引拿得不是對應字段的數據，如select sex from t1 where name= ‘kk’，我們通過輔助索引是不能直接拿到sex，但我們可以通過輔助索引拿到對應的主鍵id，再通過聚集索引找到一整行數據，再從一整行數據中拿到sex值，種操作叫回表，
三、MySQL索引管理
1，功能
索引的功能就是加快查找，mysql中primary key，unique ，聯合唯一都是索引，這些索引除了加速查找之外，還有約束的功能。
2，MySQL常用的索引
復制代碼
普通索引INDEX：加速查找
唯一索引：
-主鍵索引PRIMARY KEY：加速查找+約束（不為空、不能重復）
-唯一索引UNIQUE:加速查找+約束（不能重復）
聯合索引：
-PRIMARY KEY(id,name):聯合主鍵索引
-UNIQUE(id,name):聯合唯一索引
-INDEX(id,name):聯合普通索引
復制代碼
3，創建/刪除索引的語法
復制代碼
方法一：創建表時
CREATE TABLE 表名 (
字段名1 數據類型 [完整性約束條件…],
字段名2 數據類型 [完整性約束條件…],
[UNIQUE | FULLTEXT | SPATIAL ] INDEX | KEY
[索引名] (字段名[(長度)] [ASC |DESC])
);
方法二：CREATE在已存在的表上創建索引
CREATE [UNIQUE | FULLTEXT | SPATIAL ] INDEX 索引名
ON 表名 (字段名[(長度)] [ASC |DESC]) ;
方法三：ALTER TABLE在已存在的表上創建索引
ALTER TABLE 表名 ADD [UNIQUE | FULLTEXT | SPATIAL ] INDEX
索引名 (字段名[(長度)] [ASC |DESC]) ;
刪除索引：DROP INDEX 索引名 ON 表名字;
復制代碼
示范代碼
復制代碼
方式一
create table t1(
id int,
name char,
age int,
sex enum('male','female'),
unique key uni_id(id),
index ix_name(name) #index沒有key
);
方式二
create index ix_age on t1(age);
方式三
alter table t1 add index ix_sex(sex);
查看
mysql> show create table t1;
| t1 | CREATE TABLE t1 (
id int(11) DEFAULT NULL,
name char(1) DEFAULT NULL,
age int(11) DEFAULT NULL,
sex enum('male','female') DEFAULT NULL,
UNIQUE KEY uni_id (id),
KEY ix_name (name),
KEY ix_age (age),
KEY ix_sex (sex)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
復制代碼
四、正確使用索引
首先，我們得有一個認識，建立索引確實可以幫助我們加速查詢，而且可以建立輔助索引，但並不是說我們把每個字段都給加上輔助索引然后就會很方便，其實在索引存在很多的時候，會讓應用程序的性能受到影響，在建立多少索引這問題上，應該找到一個平衡點。
其次，在我們添加了索引以后並不是一定查找速度就很快，這和我們如何去查找有關，比如下面幾種情況：
1，范圍問題、或者條件不明確，條件中出現這些符號或關鍵字：>,<,>=,<=,!=,between and
出現上面的情況相當於不是精確查找，而是給的一個范圍或者是模糊查找，這導致查找的時候還得去一一進行比較，所以效率也不高，當我們查找的范圍越大時，肯定是越慢的，當查找范圍越小時，肯定是越快的
2，like
當查找條件中出現like時，若沒有%，_符號時，如‘xx’就是精確查找，速度很快的；當有符號時，當符號在前時，如‘%xx’,根據最左匹配原則，肯定先匹配%，由於%代表任意字符，所以會導致把所有的數據都要匹配一下，這效率沒有提高；但當符號在后就不一樣了，如‘xx%’，根據最左匹配原則，先匹配上xx，此時就可以把很多給直接排除，導致速度也很快。
3，盡量選擇區分度高的字段作為索引，比如我們選擇性別作為索引，不是男的就是女的，在查詢的時候回得到很多數據，這樣也會很慢，而且沒有實際意義
復制代碼
我們編寫存儲過程為表s1批量添加記錄，name字段的值均為egon，也就是說name這個字段的區分度很低（gender字段也是一樣的，我們稍后再搭理它）
回憶b+樹的結構，查詢的速度與樹的高度成反比，要想將樹的高低控制的很低，需要保證：在某一層內數據項均是按照從左到右，從小到大的順序依次排開，即左1<左2<左3<...
而對於區分度低的字段，無法找到大小關系，因為值都是相等的，毫無疑問，還想要用b+樹存放這些等值的數據，只能增加樹的高度，字段的區分度越低，則樹的高度越高。極端的情況，索引字段的值都一樣，那么b+樹幾乎成了一根棍。本例中就是這種極端的情況，
name字段所有的值均為'egon'
現在我們得出一個結論：為區分度低的字段建立索引，索引樹的高度會很高，然而這具體會帶來什么影響呢？？？
1：如果條件是name='xxxx',那么肯定是可以第一時間判斷出'xxxx'是不在索引樹中的（因為樹中所有的值均為'egon’,看第一條的時候就知道你不在索引樹里面了），所以查詢速度很快
2：如果條件正好是name='egon',查詢時，我們永遠無法從樹的某個位置得到一個明確的范圍，只能往下找，往下找，往下找。。。這與全表掃描的IO次數沒有多大區別，所以速度很慢
復制代碼
4，索引最好不要參與計算，比如把條件寫成where id*3=3000,這樣相當於每次都要把id拿來計算一下才比，把所有數據都過一遍，很慢的，但我們寫成where id = 3000/3，條件是一樣的，但銷量就高很多
5，and，or
復制代碼
1、and與or的邏輯
條件1 and 條件2:所有條件都成立才算成立，但凡要有一個條件不成立則最終結果不成立
條件1 or 條件2:只要有一個條件成立則最終結果就成立
2、and的工作原理
條件：
a = 10 and b = 'xxx' and c > 3 and d =4
索引：
制作聯合索引(d,a,b,c)
工作原理: #如果是你找的話，你會怎么找，是不是從左到右一個一個的比較啊，首先你不能確定a這個字段是不是有索引，即便是有索引，也不一定能確保命中索引了（所謂命中索引，就是應用上了索引），mysql不會這么笨的，看下面mysql是怎么找的：
索引的本質原理就是先不斷的把查找范圍縮小下來，然后再進行處理，對於連續多個and：mysql會按照聯合索引，從左到右的順序找一個區分度高的索引字段(這樣便可以快速鎖定很小的范圍)，加速查詢，即按照d—>a->b->c的順序
3、or的工作原理
條件：
a = 10 or b = 'xxx' or c > 3 or d =4
索引：
制作聯合索引(d,a,b,c)
工作原理:
只要一個匹配成功就行，所以對於連續多個or：mysql會按照條件的順序，從左到右依次判斷，即a->b->c->d
復制代碼
五、聯合索引與覆蓋索引
1，聯合索引
聯合索引就是把表的多個字段合起來作為一個索引。
復制代碼
mysql> create table t(
-> a int,
-> b int,
-> primary key(a),
-> key idx_a_b(a,b)
-> );
Query OK, 0 rows affected (0.11 sec)
復制代碼
上圖就是一個聯合索引的數據結構圖，是按照（a，b）的順序進行了存放。
select * from t1 where a=2 and b=1;這是可以使用聯合索引加速查詢的
select * from t1 where a=3；這也可以用聯合索引加速查詢的，可以看出是按a排序的
但是，select * from t1 where b=2；這是不能使用聯合索引加速查詢的，因為不是按b排序，從上到下，從左到右，b的值都是亂的
注意：建立聯合索引時，把區分度高的放在前面，即最左邊，依次排下去，范圍查詢放在后面
聯合索引第二好處：第一個字段的值相同時，就已經對第二個字段的值進行了排序，上圖中的a為1時，b的值從左往右增大的，排好序了的
復制代碼
create table buy_log(
userid int unsigned not null,
buy_date date
);
insert into buy_log values
(1,'2009-01-01'),
(2,'2009-01-01'),
(3,'2009-01-01'),
(1,'2009-02-01'),
(3,'2009-02-01'),
(1,'2009-03-01'),
(1,'2009-04-01');
alter table buy_log add key(userid);
alter table buy_log add key(userid,buy_date);
=驗證====
mysql> show create table buy_log;
| buy_log | CREATE TABLE buy_log (
userid int(10) unsigned NOT NULL,
buy_date date DEFAULT NULL,
KEY userid (userid),
KEY userid_2 (userid,buy_date)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
可以看到possible_keys在這里有兩個索引可以用，分別是單個索引userid與聯合索引userid_2,但是優化器最終選擇了使用的key是userid因為該索引的葉子節點包含單個鍵值，所以理論上一個頁能存放的記錄應該更多
mysql> explain select * from buy_log where userid=2;
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
| 1 | SIMPLE | buy_log | ref | userid,userid_2 | userid | 4 | const | 1 | |
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
row in set (0.00 sec)
接着假定要取出userid為1的最近3次的購買記錄，用的就是聯合索引userid_2了，因為在這個索引中，在userid=1的情況下，buy_date都已經排序好了
mysql> explain select * from buy_log where userid=1 order by buy_date desc limit 3;
+----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+
| 1 | SIMPLE | buy_log | ref | userid,userid_2 | userid_2 | 4 | const | 4 | Using where; Using index |
+----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+
row in set (0.00 sec)
ps：如果extra的排序顯示是Using filesort，則意味着在查出數據后需要二次排序(如下查詢語句，沒有先用where userid=3先定位范圍，於是即便命中索引也沒用，需要二次排序)
mysql> explain select * from buy_log order by buy_date desc limit 3;
+----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+
| 1 | SIMPLE | buy_log | index | NULL | userid_2 | 8 | NULL | 7 | Using index; Using filesort |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+
對於聯合索引（a,b）,下述語句可以直接使用該索引，無需二次排序
select ... from table where a=xxx order by b;
然后對於聯合索引(a,b,c)來首，下列語句同樣可以直接通過索引得到結果
select ... from table where a=xxx order by b;
select ... from table where a=xxx and b=xxx order by c;
但是對於聯合索引(a,b,c)，下列語句不能通過索引直接得到結果，還需要自己執行一次filesort操作，因為索引（a，c)並未排序
select ... from table where a=xxx order by c;
復制代碼
2，覆蓋索引
上面講了，利用輔助索引拿到輔助索引對應字段的值，不需要從聚集索引中拿整行數據的操作叫覆蓋索引。輔助索引不包含整行數據，其大小遠小於聚集索引，因此減少大量的IO操作。
2.1對於統計問題而言，相較於聚集索引，還是會選擇輔助索引，這是優化器的操作結果
復制代碼
mysql> explain select count(*) from buy_log;
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
| 1 | SIMPLE | buy_log | index | NULL | userid | 4 | NULL | 7 | Using index |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
row in set (0.00 sec)
復制代碼
2.2對於（a，b）形式的聯合索引，一般不可以選擇b的查詢條件，相當於說查詢條件中沒有a，只有b時是用不到聯合索引的，但是做統計操作時，優化器還是會選擇聯合索引的
復制代碼
聯合索引userid_2（userid,buy_date）,一般情況，我們按照buy_date是無法使用該索引的，但特殊情況下：查詢語句是統計操作，且是覆蓋索引，則按照buy_date當做查詢條件時，也可以使用該聯合索引
mysql> explain select count(*) from buy_log where buy_date >= '2011-01-01' and buy_date < '2011-02-01';
+----+-------------+---------+-------+---------------+----------+---------+------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+---------------+----------+---------+------+------+--------------------------+
| 1 | SIMPLE | buy_log | index | NULL | userid_2 | 8 | NULL | 7 | Using where; Using index |
+----+-------------+---------+-------+---------------+----------+---------+------+------+--------------------------+
row in set (0.00 sec)
復制代碼
六、查詢優化器-explain
優化器中，key表示采用的索引是哪一個，rows是核心指標，表示查詢過程總共需要查看幾條數據，當rows很小的語句執行一定很快的，所以優化語句基本上都是在優化rows。
使用方法：在select語句前加上explain就行了
具體查看http://www.cnblogs.com/yycc/p/7338894.html，關於優化器的詳細講解
七、查詢優化的基本步驟
復制代碼
0.先運行看看是否真的很慢，注意設置SQL_NO_CACHE
1.where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應用到表中返回的記錄數最小的表開始查起，單表每個字段分別查詢，看哪個字段的區分度最高
2.explain查看執行計划，是否與1預期一致（從鎖定記錄較少的表開始查詢）
3.order by limit 形式的sql語句讓排序的表優先查
4.了解業務方使用場景
5.加索引時參照建索引的幾大原則
6.觀察結果，不符合預期繼續從0分析
復制代碼
八、慢日志管理
復制代碼
慢日志
- 執行時間 > 10
- 未命中索引
- 日志文件路徑
配置：
- 內存
show variables like '%query%';
show variables like '%queries%';
set global 變量名 = 值
- 配置文件
mysqld --defaults-file='E:\wupeiqi\mysql-5.7.16-winx64\mysql-5.7.16-winx64\my-default.ini'
my.conf內容：
slow_query_log = ON
slow_query_log_file = D:/....
注意：修改配置文件之后，需要重啟服務
復制代碼
復制代碼
MySQL日志管理
錯誤日志: 記錄 MySQL 服務器啟動、關閉及運行錯誤等信息
二進制日志: 又稱binlog日志，以二進制文件的方式記錄數據庫中除 SELECT 以外的操作
查詢日志: 記錄查詢的信息
慢查詢日志: 記錄執行時間超過指定時間的操作
中繼日志： 備庫將主庫的二進制日志復制到自己的中繼日志中，從而在本地進行重放
通用日志： 審計哪個賬號、在哪個時段、做了哪些事件
事務日志或稱redo日志： 記錄Innodb事務相關的如事務執行時間、檢查點等
一、bin-log
- 啟用
vim /etc/my.cnf
[mysqld]
log-bin[=dir[filename]]
service mysqld restart
- 暫停
//僅當前會話
SET SQL_LOG_BIN=0;
SET SQL_LOG_BIN=1; - 查看
查看全部：
mysqlbinlog mysql.000002
按時間：
mysqlbinlog mysql.000002 --start-datetime="2012-12-05 10:02:56"
mysqlbinlog mysql.000002 --stop-datetime="2012-12-05 11:02:54"
mysqlbinlog mysql.000002 --start-datetime="2012-12-05 10:02:56" --stop-datetime="2012-12-05 11:02:54"
按字節數：
mysqlbinlog mysql.000002 --start-position=260
mysqlbinlog mysql.000002 --stop-position=260
mysqlbinlog mysql.000002 --start-position=260 --stop-position=930
- 截斷bin-log（產生新的bin-log文件）
a. 重啟mysql服務器
b. # mysql -uroot -p123 -e 'flush logs' - 刪除bin-log文件
mysql -uroot -p123 -e 'reset master'
二、查詢日志
啟用通用查詢日志
vim /etc/my.cnf
[mysqld]
log[=dir[filename]]
service mysqld restart
三、慢查詢日志
啟用慢查詢日志
vim /etc/my.cnf
[mysqld]
log-slow-queries[=dir[filename]]
long_query_time=n
service mysqld restart
MySQL 5.6:
slow-query-log=1
slow-query-log-file=slow.log
long_query_time=3
查看慢查詢日志
測試:BENCHMARK(count,expr)
SELECT BENCHMARK(50000000,2*3);