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