高性能MySQL-筆記4-所謂的高級的東東

高性能MySQL-筆記4-所謂的高級的東東

分區表的一些注意點

• 分區表是各個子表的透明封裝，索引也按照子表的，所有不存在全局索引。
• 對null值會存放在單獨第一分區，默認掃描的。
• 【分區的限制和查詢有很多，並不是什麼特別提示性能的東東，可以參考之前InnoDB的筆記】

視圖的東東

略過，沒事別用就對了。沒啥子的性能優化效果。

內部代碼【存儲、函數等】

• 定時事件是有線程池的：event_scheduler :=N ;

構建動態SQL

set @sql := 'select ....from table where pare_1 = ?';
PREPARE xxxfindsql from @sql;
set @canshu := '123';
EXECUTE xxxfindsql USING @canshu ;

查詢緩存 ！！

• 如果變發生變化，則與之相關的所有緩存數據失效。【辣麼實時表、操作密集表的失效可能很大】

  • 建議是關閉查詢緩存或者配置很小的查詢緩存空間？？

  • show variables like '%query_cache%'; 
    
    如果不是ON，修改配置文件以開啓查詢緩存：
    > vi /etc/my.cnf
    [mysqld]中添加：
    query_cache_size = 20M
    query_cache_type = ON
     
    重啓mysql服務：
    > service mysql restart
    
    查看緩存使用情況：[P316~318]
    show status like 'qcache%';  
    show status like 'com_select%';  
    命中率：Qcache_hits/(Com_select+Qcache_hits)    [失效原因分析P315]
    命中和寫入比率：Qcache_hits：Qcache_inserts   （3:1 以上有效  10:1 就很好的了）
    
    

  • 緩存命中的限制很多，操作表而進行緩存失效時，使用全局鎖保護（命中，失效，緩存都靠這個鎖），在緩存太大時，系統可能僵死。

• 使用 SQL_CACHE 和 query_cache_type = DEMAND 可以手動控制查詢緩存

• 感覺沒啥事，還是把它關了的好。可能出事，限制還多。。。ε=(´ο｀*)))唉

• 代替方案。。 我覺得一些的不經常變更的，數據量小的，丟到項目 Redis 緩存去好了 ╮(╯_╰)╭

---

小杭 2020-02-10 感覺這些高級功能都呀的難用啊 (╯‵□′)╯︵┻━┻