第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

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)相同，即表列字段相同。

方法：

1. 對(duì)custom_id用到hash操作, 若拆成個(gè)水平表，mod(custom_id,5)取出0-4個(gè)值；

2. 針對(duì)不同hashID把數(shù)據(jù)存到不同的表中。

前臺(tái)使用拆分后的表，方便使用，后臺(tái)使用匯總表，方便統(tǒng)計(jì)以及后天報(bào)表操作。

垂直拆分三原則(分別三種情況)：

1. 不常用

2. 大字段

3. 經(jīng)常用

例子中，拆分后兩個(gè)表都有一個(gè)film_id,這就是垂直拆分后兩個(gè)表的關(guān)聯(lián)所在。

為提高io讀的效率，犧牲一些存儲(chǔ)空間的代價(jià)。但是提高了讀取數(shù)據(jù)的效率。

如用戶常常會(huì)大量查詢訂單的信息，那么吧用戶名，電話，地址和訂單價(jià)格放入一個(gè)訂單表中，雖然違反了第三范式，因?yàn)橛唵蝘d，用戶名，電話，地址等，存在傳遞函數(shù)依賴，但是由于數(shù)據(jù)都是在一張表中，方便了sql語句實(shí)現(xiàn)，訂單信息的讀取，從而優(yōu)化了io性能；

一般來說 是對(duì)符合第三范式的表結(jié)構(gòu)進(jìn)行設(shè)計(jì)，在設(shè)計(jì)之前，就要考察表是否符合第三范式要求；有無存在非關(guān)鍵字段對(duì)某一關(guān)鍵字段的傳遞函數(shù)依賴。

合適的數(shù)據(jù)類型選擇：

1.最小數(shù)據(jù)存儲(chǔ)原則；

2.簡(jiǎn)單數(shù)據(jù)類型原則；

3.NOT NULL字段盡可能用，因?yàn)槿绻患樱捎趇nnodb的存儲(chǔ)特性，對(duì)于非not null 的（沒聽清楚）表會(huì)有額外字段來存儲(chǔ)；

4盡量少text類型；

由于用戶變更等可能性，有些索引不再使用，因此需要?jiǎng)h除不用索引。

1.維護(hù)和刪除冗余索引：

?2：30：

聯(lián)合索引中包含了主鍵：innodb的特性，它會(huì)自動(dòng)在每個(gè)索引后附加一個(gè)主鍵，

因此人為添加主鍵信息key（name，id）就是一個(gè)冗余索引；

2.? ? 2：57 ：查找重復(fù)及冗余索引的sql語句

要在information_schema數(shù)據(jù)庫(kù)運(yùn)行該語句

3. 使用pt-duplicate-key-checker工具查找重復(fù)及冗余索引

1.索引的建立：

在條件從句中建立索引：

如：where ， order by， group by， on 從句

2. 索引字段越小越好。?

使得一頁存儲(chǔ)的數(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處理，因此常常會(huì)是用filesort，因此造成大量io問題。

使用limit語句時(shí)，要考慮io問題可否進(jìn)一步優(yōu)化。

1：44顯示，order by 操作中使用了表掃描的操作（type：all），產(chǎn)生大量io問題。（盡量用少的讀寫實(shí)現(xiàn)問題的解決）

優(yōu)化方法步驟：

1.使用有索引的列或者逐漸進(jìn)行order by 操作；（優(yōu)化前是order by title非主鍵，優(yōu)化后是order by film_id,是主鍵）；

2.偏移量(翻頁的掃描數(shù)據(jù)量會(huì)隨著偏移量增加而增加)優(yōu)化：記錄上次返回的主鍵，在下次查詢時(shí)使用主鍵過濾（where 主鍵從句）；如：

偏移量是55，一頁是5行數(shù)據(jù)， where film_id>55 and film_id<=60，則限定了從第56行查起，查到60行為止，從而大大降低了數(shù)據(jù)的掃描io操作；

這樣直接可以避免掃描過多的記錄。

其實(shí)也是在了解了limit執(zhí)行方式之后，在不違反limit語句后臺(tái)執(zhí)行方式的邏輯下，對(duì)limit的操作進(jìn)行了sql語句的限制，從而優(yōu)化limit的io性能。

優(yōu)化前（1：02）;并未時(shí)候用where語句，因此后臺(tái)會(huì)出現(xiàn)頁表掃描的情況，降低sql執(zhí)行效率。后臺(tái)仍然使用了臨時(shí)表和文件排序的操作。

優(yōu)化后：利用關(guān)聯(lián)子查詢，查到了每一個(gè)演員id對(duì)應(yīng)影片數(shù)量，再跟演員表關(guān)聯(lián)，查詢到了演員姓名，以及對(duì)應(yīng)的影片數(shù)量。（當(dāng)然二者from的表都不一樣，優(yōu)化前是from film_actor,優(yōu)化后是from actor，可能二者不同表之間數(shù)據(jù)量也存在差異）

優(yōu)化前（1：02）;并未時(shí)候用where語句，因此后臺(tái)會(huì)出現(xiàn)頁表掃描的情況，降低sql執(zhí)行效率。后臺(tái)仍然使用了臨時(shí)表和文件排序的操作。

優(yōu)化后：利用關(guān)聯(lián)子查詢，查到了每一個(gè)演員id對(duì)應(yīng)影片數(shù)量，再跟演員表關(guān)聯(lián)，查詢到了演員姓名。

在子查詢的優(yōu)化中：

通常做法是把需要的子查詢優(yōu)化為join查詢，但在優(yōu)化時(shí)要注意是否有數(shù)據(jù)的重復(fù)，因?yàn)樵陉P(guān)聯(lián)語句中的可能存在一對(duì)多的關(guān)系，從而造成數(shù)據(jù)冗余。

join語句是相當(dāng)于將多個(gè)表進(jìn)行關(guān)聯(lián)，在關(guān)聯(lián)條件上一一進(jìn)行條件匹配查詢，因此返回值不僅取決于原始表中的數(shù)據(jù)個(gè)數(shù)，還取決于其他表中與之匹配的數(shù)據(jù)的個(gè)數(shù)。

所以要加上distinct

具體:3:08: select distinct t.id from t join t1 on t.id=t1.tid;

邏輯上的sql優(yōu)化具體案例（需要大量經(jīng)驗(yàn)和自我總結(jié)得到）：

max()語句優(yōu)化：

1：44：看到rows 非常高，說明sql語句效率不高；

這時(shí)候優(yōu)化思路是：可以在'payment_date'上建立索引

create index idx_paydate on payment(payment_date);

這時(shí)候 在執(zhí)行max（payment_date）后rows為null，說明執(zhí)行效率很高，

因?yàn)樗饕琼樞蚺帕械模ㄟ^索引統(tǒng)計(jì)信息就可以知道，最后一個(gè)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的特點(diǎn)，（這也是需要經(jīng)驗(yàn)的），count（*）中，若遇到null返回值為1；