插入數據優化，

insert 優化，

????????批量插入（一次不超過1000條）

? ? ? ? 手動提交事務

????????主鍵順序插入

load 從本地一次插入大批量數據，

登陸時 mysql --local-infile -u root -p

load data local infile '/root/sql1.log' into table 'tb_user' fields terminated by ',' lines terminated by '\n';

從?'/root/sql1.log' 文件中，讀取加載數據，加載數據到?tb_user 這個表，每個字段用 逗號分隔，每一行用 換行回車 分隔。

通過 select? @@loacl_infile;查看是否打開可以批量插入數據的變量，

如果沒有打開，則通過 set??loacl_infile = 1; 打開該變量

主鍵優化，

我們看到 mysql innodb 中的 表數據 都是 根據主鍵順序組織存放的。

page 是 innoDB的最小管理。

在主鍵順序插入時，頁中數據的形式

頁分裂 - 在主鍵 亂序 插入時，頁中數據可能會引起 頁分裂

頁合并

原始數據

依次刪除 16,15,14,13 時

主鍵設計原則

主鍵長度 太長，輔助索引浪費更多的空間。

盡量順序插入，選擇使用 auto_incrment 避免 頁分裂。

order by優化，

?說白了，就是我們在 查詢到數據后，在排序的時候使用order by 后面的字段 也是需要有 索引的。

如果排序后面的字段有索引，那么 explain select 執行后，extra 后面會提示 using index，表明我們的排序是使用的? 索引完成的。

如果排序后面的字段沒有索引，則extra后面的提示是 using filesort，表明排序沒有使用索引。?

測試，發現 extra 后面說明的 using index?

創建age 和phone 的聯合索引， 默認情況下 age和phone 都會按照 升序 排序。

如果我們像要讓 age 按照 升序排序，讓 phone 按照降序排序，則，按照如下的寫法。

默認排序緩沖大小的值，在 變量 sort_buffer_size中存儲。如果查詢到的數據量就是很大，256k已經不夠用了，默認mysql 就會在磁盤文件中開辟空間，I/O就會很慢。因此我們可以 改動?sort_buffer_size的大小，避免在 磁盤文件中開辟空間。

group by 優化，

limit 優化，

count 優化，

簡單來說，count 優化是要自己計數的。

如果不優化，就使用count(*)計數，這個效率是最高的。

由于 id =24 沒有專業，因此 select count(prefession) from tb_user的值是23

也就是說，如果按照字段計數，如果該字段為null，則不會計數。

update 優化

這是啥意思呢？ 我們假設 student 表有3條記錄

id? ?name? ? no

1? 張三豐? 2000100100

2 韋一笑? ?2000100105

3? 度小滿?2000100106

索引 只有 primary key? = id，

我們有兩個并行的事務，

一個按照id 更新 no，一個按照 name 更新 no

由于id 是有索引的，因此只會 鎖定? id =1 的這一行，

但是name沒有索引，會鎖定 整張表，

也就是下面說的，innoDB的韓所是針對索引加的鎖。

如果沒有索引，會變成整張表的 鎖。

應盡量避免將 整張表的鎖。

這會讓并行效率變的很低。