如今业内经常使用的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_