-
00：51：使用該語句查找mysql的配置文件的順序。
查看全部 -
網絡方面的配置，需要修改/etc/sysctl.conf文件
修改/etc/security/limits.conf文件，可修改打開文件數量的限制
* soft nofile 65535
*hard nofile 65535
最好關閉防火墻軟件，使用硬件防火墻代替（？）。
查看全部 -
1. 水平拆分：解決數據量的問題。
行數代表了具體的數據量大小。
2. 水平拆分后，表結構相同，即表列字段相同。
方法：
對custom_id用到hash操作, 若拆成個水平表，mod(custom_id,5)取出0-4個值；
針對不同hashID把數據存到不同的表中。
前臺使用拆分后的表，方便使用，后臺使用匯總表，方便統計以及后天報表操作。
查看全部 -
垂直拆分三原則(分別三種情況)：
不常用
大字段
經常用
例子中，拆分后兩個表都有一個film_id,這就是垂直拆分后兩個表的關聯所在。
查看全部 -
為提高io讀的效率，犧牲一些存儲空間的代價。但是提高了讀取數據的效率。
如用戶常常會大量查詢訂單的信息，那么吧用戶名，電話，地址和訂單價格放入一個訂單表中，雖然違反了第三范式，因為訂單id，用戶名，電話，地址等，存在傳遞函數依賴，但是由于數據都是在一張表中，方便了sql語句實現，訂單信息的讀取，從而優化了io性能；
查看全部 -
一般來說 是對符合第三范式的表結構進行設計，在設計之前，就要考察表是否符合第三范式要求；有無存在非關鍵字段對某一關鍵字段的傳遞函數依賴。
查看全部 -
合適的數據類型選擇：
1.最小數據存儲原則；
2.簡單數據類型原則；
3.NOT NULL字段盡可能用，因為如果不加，由于innodb的存儲特性，對于非not null 的（沒聽清楚）表會有額外字段來存儲；
4盡量少text類型；
查看全部 -
由于用戶變更等可能性，有些索引不再使用，因此需要刪除不用索引。
查看全部 -
1.維護和刪除冗余索引：
?2：30：
聯合索引中包含了主鍵：innodb的特性，它會自動在每個索引后附加一個主鍵，
因此人為添加主鍵信息key（name，id）就是一個冗余索引；
2.? ? 2：57 ：查找重復及冗余索引的sql語句
要在information_schema數據庫運行該語句
3. 使用pt-duplicate-key-checker工具查找重復及冗余索引
查看全部 -
1.索引的建立：
在條件從句中建立索引：
如：where ， order by， group by， on 從句
2. 索引字段越小越好。?
使得一頁存儲的數據量增大，使得io效率更好。
3.離散度大的列放到聯合索引前面,離散度高，可選擇性更好,放在前面效果越好；
判斷列離散度的語句
select count(distinct custom_id), count(distinct staff_id) from payment;
所以選擇聯合索引 index(custom_id,staff_id)
查看全部 -
limit查詢本身大量伴隨order by處理，因此常常會是用filesort，因此造成大量io問題。
使用limit語句時，要考慮io問題可否進一步優化。
1：44顯示，order by 操作中使用了表掃描的操作（type：all），產生大量io問題。（盡量用少的讀寫實現問題的解決）
優化方法步驟：
1.使用有索引的列或者逐漸進行order by 操作；（優化前是order by title非主鍵，優化后是order by film_id,是主鍵）；
2.偏移量(翻頁的掃描數據量會隨著偏移量增加而增加)優化：記錄上次返回的主鍵，在下次查詢時使用主鍵過濾（where 主鍵從句）；如：
偏移量是55，一頁是5行數據， where film_id>55 and film_id<=60，則限定了從第56行查起，查到60行為止，從而大大降低了數據的掃描io操作；
這樣直接可以避免掃描過多的記錄。
其實也是在了解了limit執行方式之后，在不違反limit語句后臺執行方式的邏輯下，對limit的操作進行了sql語句的限制，從而優化limit的io性能。
查看全部 -
優化前（1：02）;并未時候用where語句，因此后臺會出現頁表掃描的情況，降低sql執行效率。后臺仍然使用了臨時表和文件排序的操作。
優化后：利用關聯子查詢，查到了每一個演員id對應影片數量，再跟演員表關聯，查詢到了演員姓名，以及對應的影片數量。（當然二者from的表都不一樣，優化前是from film_actor,優化后是from actor，可能二者不同表之間數據量也存在差異）
查看全部 -
優化前（1：02）;并未時候用where語句，因此后臺會出現頁表掃描的情況，降低sql執行效率。后臺仍然使用了臨時表和文件排序的操作。
優化后：利用關聯子查詢，查到了每一個演員id對應影片數量，再跟演員表關聯，查詢到了演員姓名。
查看全部 -
在子查詢的優化中：
通常做法是把需要的子查詢優化為join查詢，但在優化時要注意是否有數據的重復，因為在關聯語句中的可能存在一對多的關系，從而造成數據冗余。
join語句是相當于將多個表進行關聯，在關聯條件上一一進行條件匹配查詢，因此返回值不僅取決于原始表中的數據個數，還取決于其他表中與之匹配的數據的個數。
所以要加上distinct
具體:3:08: select distinct t.id from t join t1 on t.id=t1.tid;
查看全部 -
邏輯上的sql優化具體案例（需要大量經驗和自我總結得到）：
max()語句優化：
1：44：看到rows 非常高，說明sql語句效率不高；
這時候優化思路是：可以在'payment_date'上建立索引
create index idx_paydate on payment(payment_date);
這時候 在執行max（payment_date）后rows為null，說明執行效率很高，
因為索引是順序排列的，通過索引統計信息就可以知道，最后一個payment_date的數值是怎么樣的，所以不需要經過表數據查詢即可知道max()結果。
完全可以通過索引信息查到我們需要的結果，稱為“覆蓋”索引；
count()優化：
3：37：sql語句邏輯上不符合我們的具體要求了；
4：52 優化后的語句邏輯上符合要求：
用到了count(null)返回值為0的特點，（這也是需要經驗的），count（*）中，若遇到null返回值為1；
查看全部
舉報