《高性能mysql》之MySQL高级特性(第七章)
生活随笔
收集整理的這篇文章主要介紹了
《高性能mysql》之MySQL高级特性(第七章)
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
①分區(qū)表:
?????-- 分區(qū)表限制:
一把表最多1024個(gè)分區(qū)
分區(qū)表中無法使用外鍵約束
???-- 分區(qū)表注意點(diǎn): 按行寫入大量數(shù)據(jù)時(shí)分區(qū)過多會(huì)出現(xiàn)問題,所以對大多數(shù)系統(tǒng),100左右個(gè)分區(qū)是沒有問題的 注:鍵分區(qū)和哈希分區(qū)沒有此問題
-- 查詢優(yōu)化:對于訪問分區(qū)來說,在where中帶分區(qū)列是很重要的(能過濾部分分區(qū)) ?注:where中要使用分區(qū)函數(shù)列本身才能過濾分區(qū),如where time='2017',而where YEAR(time)=2017錯(cuò)誤 ②視圖: 概念:虛擬表,不存數(shù)據(jù),數(shù)據(jù)來自其他表 更新視圖:更新列必須來自同一表,且含GROUP BY、UNION、聚合函數(shù)及特殊情況不能更新 對性能的影響:重構(gòu)數(shù)據(jù)庫時(shí)可使用視圖而不必修改表結(jié)構(gòu),用視圖創(chuàng)建基于列的權(quán)限控制減少額外開銷等 視圖的限制:不支持物化視圖(即視圖在表中不可查看),不支持視圖中建索引
③外鍵索引: InnoDB是mysql目前唯一支持外鍵索引的內(nèi)置引擎 外鍵成本:外鍵每次修改數(shù)據(jù)時(shí)都要求在另一張表多執(zhí)行一次查找,當(dāng)然外鍵在相關(guān)數(shù)據(jù)刪除和更新上比在應(yīng)用中維護(hù)更高效。 注:許多案例中發(fā)現(xiàn),在對性能分析時(shí)發(fā)現(xiàn)外鍵就是瓶頸所在,刪除外鍵后性能立即大幅提升。
④在mysql內(nèi)部存儲(chǔ)代碼: 存儲(chǔ)過程和觸發(fā)器(可在你執(zhí)行insert、update、delete時(shí)觸發(fā))、游標(biāo) ?---另開文章細(xì)說
⑤字符集和校對: 字符集編碼優(yōu)先級(jí):列>表>數(shù)據(jù)庫 校對規(guī)則:_cs、_ci、_bin分別對應(yīng) 大小寫不敏感、大小寫敏感、二進(jìn)制值
⑥全文索引: mysql不支持中文全文索引,應(yīng)用其他引擎如 Sphinx等 ⑦分布式(XA)事務(wù): 企業(yè)報(bào)在分布式多數(shù)據(jù)庫下仍能保證事務(wù)的ACID
⑧查詢緩存: -- 概念:緩存select結(jié)果,跳過解析、優(yōu)化、執(zhí)行階段。 查詢緩存是完全存儲(chǔ)在內(nèi)存中。mysql無法為每一個(gè)查詢結(jié)果精確分配大小剛好配匹的緩存空間。 -- 查詢緩存無法命中的原因:包含不確定的函數(shù)、未處理過該查詢、內(nèi)存用完被逐出 -- 如何判斷查詢緩存是否有效: ? ?? 查看Qache_hits和Qache_inserts的比值(3:1查詢緩存有效,10:1最佳) -- 配置和維護(hù)查詢緩存: query_cache_type:是否打開查詢緩存,設(shè)置成ON、OFF、DEMAND(這個(gè)僅在明確寫明SQL_CACHE下才放入緩存) query_cache_size:查詢緩存使用的總內(nèi)存空間(值是1024整數(shù)倍) query_cache_min_res_unit:查詢緩存中分配內(nèi)存塊時(shí)的最小單位。 query_cache_limit:MySQL能緩存的最大查詢結(jié)果 query_cache_wlock_invalidate:某表被鎖住,是否仍然從查詢緩存返回結(jié)果,默認(rèn)OFF 減少碎片:命令 FLUSH QUERY CACHE ?完成碎片整理 ?-- InnoDB和查詢緩存:表上有任何的鎖,該查詢結(jié)果無法緩存;sql語句有ON DELETE CASCADE,則相關(guān)聯(lián)查詢緩存一起失效 通用查詢緩存優(yōu)化:1) 用多個(gè)小表代替一個(gè)大表對查詢緩存 2)批量寫入時(shí)只需要做一次緩存失效 3)緩存空間太大,服務(wù)器可能僵死,辦法是控制大小或禁用 4)用SQL_CACHE、SQL_NO_CACHE控制某個(gè)select是否緩存 5)對于寫密集型應(yīng)用,直接禁用查詢緩存更好 注:若需要更高的緩存效率,推薦使用memcached或redis之類
???-- 分區(qū)表注意點(diǎn): 按行寫入大量數(shù)據(jù)時(shí)分區(qū)過多會(huì)出現(xiàn)問題,所以對大多數(shù)系統(tǒng),100左右個(gè)分區(qū)是沒有問題的 注:鍵分區(qū)和哈希分區(qū)沒有此問題
-- 查詢優(yōu)化:對于訪問分區(qū)來說,在where中帶分區(qū)列是很重要的(能過濾部分分區(qū)) ?注:where中要使用分區(qū)函數(shù)列本身才能過濾分區(qū),如where time='2017',而where YEAR(time)=2017錯(cuò)誤 ②視圖: 概念:虛擬表,不存數(shù)據(jù),數(shù)據(jù)來自其他表 更新視圖:更新列必須來自同一表,且含GROUP BY、UNION、聚合函數(shù)及特殊情況不能更新 對性能的影響:重構(gòu)數(shù)據(jù)庫時(shí)可使用視圖而不必修改表結(jié)構(gòu),用視圖創(chuàng)建基于列的權(quán)限控制減少額外開銷等 視圖的限制:不支持物化視圖(即視圖在表中不可查看),不支持視圖中建索引
③外鍵索引: InnoDB是mysql目前唯一支持外鍵索引的內(nèi)置引擎 外鍵成本:外鍵每次修改數(shù)據(jù)時(shí)都要求在另一張表多執(zhí)行一次查找,當(dāng)然外鍵在相關(guān)數(shù)據(jù)刪除和更新上比在應(yīng)用中維護(hù)更高效。 注:許多案例中發(fā)現(xiàn),在對性能分析時(shí)發(fā)現(xiàn)外鍵就是瓶頸所在,刪除外鍵后性能立即大幅提升。
④在mysql內(nèi)部存儲(chǔ)代碼: 存儲(chǔ)過程和觸發(fā)器(可在你執(zhí)行insert、update、delete時(shí)觸發(fā))、游標(biāo) ?---另開文章細(xì)說
⑤字符集和校對: 字符集編碼優(yōu)先級(jí):列>表>數(shù)據(jù)庫 校對規(guī)則:_cs、_ci、_bin分別對應(yīng) 大小寫不敏感、大小寫敏感、二進(jìn)制值
⑥全文索引: mysql不支持中文全文索引,應(yīng)用其他引擎如 Sphinx等 ⑦分布式(XA)事務(wù): 企業(yè)報(bào)在分布式多數(shù)據(jù)庫下仍能保證事務(wù)的ACID
⑧查詢緩存: -- 概念:緩存select結(jié)果,跳過解析、優(yōu)化、執(zhí)行階段。 查詢緩存是完全存儲(chǔ)在內(nèi)存中。mysql無法為每一個(gè)查詢結(jié)果精確分配大小剛好配匹的緩存空間。 -- 查詢緩存無法命中的原因:包含不確定的函數(shù)、未處理過該查詢、內(nèi)存用完被逐出 -- 如何判斷查詢緩存是否有效: ? ?? 查看Qache_hits和Qache_inserts的比值(3:1查詢緩存有效,10:1最佳) -- 配置和維護(hù)查詢緩存: query_cache_type:是否打開查詢緩存,設(shè)置成ON、OFF、DEMAND(這個(gè)僅在明確寫明SQL_CACHE下才放入緩存) query_cache_size:查詢緩存使用的總內(nèi)存空間(值是1024整數(shù)倍) query_cache_min_res_unit:查詢緩存中分配內(nèi)存塊時(shí)的最小單位。 query_cache_limit:MySQL能緩存的最大查詢結(jié)果 query_cache_wlock_invalidate:某表被鎖住,是否仍然從查詢緩存返回結(jié)果,默認(rèn)OFF 減少碎片:命令 FLUSH QUERY CACHE ?完成碎片整理 ?-- InnoDB和查詢緩存:表上有任何的鎖,該查詢結(jié)果無法緩存;sql語句有ON DELETE CASCADE,則相關(guān)聯(lián)查詢緩存一起失效 通用查詢緩存優(yōu)化:1) 用多個(gè)小表代替一個(gè)大表對查詢緩存 2)批量寫入時(shí)只需要做一次緩存失效 3)緩存空間太大,服務(wù)器可能僵死,辦法是控制大小或禁用 4)用SQL_CACHE、SQL_NO_CACHE控制某個(gè)select是否緩存 5)對于寫密集型應(yīng)用,直接禁用查詢緩存更好 注:若需要更高的緩存效率,推薦使用memcached或redis之類
總結(jié)
以上是生活随笔為你收集整理的《高性能mysql》之MySQL高级特性(第七章)的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 第八十六期:“程序员锁死服务器导致公司倒
- 下一篇: 最优资产组合步骤_重新设计投资组合网站之