如今業內經常使用的MySQL高可用方案有哪些？

目錄

• 如何將excel數據導入MySQL表中？
• 用xtrabackup跑mysql物理備份，建議授予哪些權限？
• select裏用rand()，怎麼優化效率？
• 如今業內經常使用的MySQL高可用方案有哪些？
• 何時MySQL的索引"失效"不可用？
• MySQL從庫show processlist出現system lock的緣由以及解決方法有哪些？

---

1、如何將excel數據導入MySQL表中？
將excel導入MySQL表的方式有不少，這裏列舉幾種平時經常使用的方法：

一、將excel另存爲csv文件，再使用LOAD DATA導入表，命令參考以下：
LOAD DATA INFILE 'c:/tmp/discounts.csv'

INTO TABLE discounts

FIELDS TERMINATED BY ','

ENCLOSED BY '"'

LINES TERMINATED BY 'n'

IGNORE 1 ROWS;

二、利用Navicat、MySQL Workbench等第三方工具進行導入

三、excel利用函數拼接成insert SQL進行數據插入(數據量大時不推薦，效率極低)

四、例行批量導入，安利python的xlwt模塊

注意：進行數據導入時注意先執行set names設置字符集，以避免形成亂碼

2、用xtrabackup跑mysql物理備份，建議授予哪些權限？

可能須要用到如下權限：

一、RELOAD and LOCK TABLES (用於FLUSH TABLES WITH READ LOCK 和 FLUSH ENGINE LOGS)

二、BACKUP_ADMIN （用於查詢表performance_schema.log_status, 執行LOCK INSTANCE FOR BACKUP, LOCK BINLOG FOR BACKUP, 或 LOCK TABLES FOR BACKUP）

三、REPLICATION CLIENT（獲取一致性位點）

四、PROCESS（用於執行SHOW ENGINE INNODB STATUS或者查看線程狀態等）

五、SUPER（複製環境下用於start/stop the slave threads）

六、SELECT（使用選項--incremental-history-name or --incremental-history-uuid時獲取innodb_to_lsn插入到PERCONA_SCHEMA.xtrabackup_history表）

3、select裏用rand()，怎麼優化效率？

案例：

select id from t1 where id = round(rand()*13241324);

其中id列是IINT類型的主鍵

（一）問題點

該SQL的問題點主要在於當使用rand()匹配時，其實是逐行提取數據，rand()每次生成一個隨機數進行單行匹配，即若是t1表有100萬數據就會匹配100萬次，即使有索引也沒用，也要全表掃描

（二）優化方式

優化方式主要有2種思路，第一種是經過子查詢關聯，第二種是經過範圍查詢加limit 1，以下所示：

一、select id from t1 join (select round(rand()*13241324) as id2) as t2 where t1.id = t2.id2

二、select id from t1 where id > (select round(rand()*(select max(id) from t1)) as nid) limit 1

再次提醒，不要用rand()直接進行匹配或者排序，會引起性能災難

參考：

http://imysql.com/2014/07/04/...

4、如今業內經常使用的MySQL高可用方案有哪些？

目前來講，比較多的開源方案份內置高可用與外部實現，內置高可用有以下：
一、官方版本分支：MGR（首推）

二、percona分支：PXC

三、MariaDB：Galera Cluster

外部實現方案：

一、orchestrator(GTID)

二、replication-manager(GTID)

三、MHA(傳統複製)

四、MOHA(支持多AZ部署)

五、其餘...

5、何時MySQL的索引"失效"不可用？

一、經過索引掃描的記錄超過20%~30%，可能會變成全表掃描

二、聯合索引中，查詢條件不符合左側前導要求

三、查詢條件列最左以通配符%開始

四、查詢條件發生數據類型隱式轉換，或者字符集不匹配

五、HEAP表使用HASH索引時，使用範圍檢索或者ORDER BY

六、多表關聯時，排序字段不屬於驅動表，沒法利用索引完成排序

七、JOIN查詢時，關聯列數據類型（字符集）不一致也會致使索引不可用

八、不可見索引，即使force index也不可用

九、違反索引排序規則

詳情請戳：「週四見」第108期—《MySQL索引爲什麼「失效」》

6、MySQL從庫show processlist出現system lock的緣由以及解決方法有哪些？

因爲大量的小事物如UPDATE/DELETE table where一行數據，這種只包含一行DML event的語句，table是一張大表。

一、這個表上沒有主鍵或者惟一鍵，能夠考慮嘗試修改參數slave_rows_search_algorithms。

二、因爲相似innodb lock堵塞，也就是slave從庫修改了數據同時和sql_thread也在修改一樣的數據。

三、確實I/O扛不住了，修改sync_binlog/innodb_flush_log_at_trx_commit或者提升IO子系統的IO能力

友情提示：

MySQL數據庫表建議都設置int/bigint的自增主鍵，"業務主鍵"設置爲not null + 惟一索引

---

一個輕鬆的python算法題：有64瓶藥，其中63瓶是無毒的，只有一瓶是有毒的。若是小白鼠喝了有毒的藥，3天后會死掉，喝了無毒的藥，喝了多少瓶都沒事。如今只剩下3天時間，請問最少須要多少隻小白鼠才能試出哪瓶藥有毒？

總共須要六隻小白鼠。

6只小白鼠當作二進制的位數，那麼小白鼠能夠表示從000000 - 111111，也就是十進制的0-63個數，藥按照1-64排好號，好比第一瓶藥編號1，對應小白鼠000001，最右邊的小白鼠喝，以此類推，好比第8瓶藥，001000，第三隻小白鼠喝。從1-63號藥都喝一遍。假如最後死的小白鼠對應二進制是001111，那麼是15號藥有毒。

---

對文章感興趣的朋友們能夠加我哦，這裏有一個樂於交友的人鴨！

微信：lvqingshan_