http://blog.itpub.net/28916011/viewspace-2093197/
1. MYISAM和INNODB的不同？
答：主要有以下几点区别：
a)构造上的区别
MyISAM在磁盘上存储成三个文件，其中.frm文件存储表定义；.MYD (MYData)为数据文件；.MYI (MYIndex)为索引文件。
而innodb是由.frm文件、表空间（分为独立表空间或者共享表空间）和日志文件（redo log）组成。
b)事务上的区别
myisam不支持事务；而innodb支持事务。
c)锁上的区别
myisam使用的是表锁；而innodb使用的行锁（当然innodb也支持表锁）。
表级锁：直接锁定整张表，在锁定期间，其他进程无法对该表进行写操作，如果设置的是写锁，那么其他进程读也不允许，因此myisam支持的并发量低，但myisam不会出现死锁；
行级锁：只对指定的行进行锁定，其他进程还是可以对表中的其他行进行操作的。因此行锁能大大的减少数据库操作的冲突，但有时会导致死锁。
d)是否支持外键的区别
myisam不支持外键，innodb支持外键
e) select count(*)的区别
对于没有where的count(*)使用MyISAM要比InnoDB快得多。因为MyISAM内置了一个计数器，count(*)时它直接从计数器中读，而InnoDB必须扫描全表。
f)myisam只把索引都load到内存中，而innodb存储引擎是把数据和索引都load到内存中
2. 公司现有的数据库架构，总共有几组mysql库？
答：我们公司现在有两组MySQL。其中一套是生产库，一套是测试库。
生产库和测试库都是用的mha +半同步复制做的高可用。
我们所有的项目web前端量（大概有10个项目）指向的都是一个机器上的mysql实例。因为我们是传统行业，并发访问量并不是很大，所以目前我们的生产mysql数据库未出现性能问题。
3. 如何提高insert的性能？
答：有如下方法：
a)合并多条 insert 为一条，即： insert into t values(a,b,c), (d,e,f) ,,,
原因分析：主要原因是多条insert合并后日志量（MySQL的binlog和innodb的事务让日志） 减少了，降低日志刷盘的数据量和频率，从而提高效率。通过合并SQL语句，同时也能减少SQL语句解析的次数，减少网络传输的IO。
b)修改参数 bulk_insert_buffer_size， 调大批量插入的缓存；
c)设置 innodb_flush_log_at_trx_commit = 0 ，相对于 innodb_flush_log_at_trx_commit = 1 可以十分明显的提升导入速度；
（备注：innodb_flush_log_at_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：
0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file 的刷新或者文件系统到磁盘的刷新操作;
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步;
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
）
d）手动使用事务
因为mysql默认是autocommit的，这样每插入一条数据，都会进行一次commit；所以，为了减少创建事务的消耗，我们可用手工使用事务，即START TRANSACTION;insert 。。,insert。。 commit；即执行多个insert后再一起提交；一般1000条insert 提交一次。
4. 和上一个问题相关，如果insert等dml语句的性能有问题的话，或者其他问题的存在，可能造成同步延迟，所以如何有效避免同步延迟的出现？
答：MySQL主从同步延迟的最主要原因就是主库是多线程写，而从库只有一个线程（即slave_sql_running）来同步，所以在主库中如果有一个ddl或dml操作执行10分钟，那么这个操作在从库上同样需要执行10分钟。有人可能会问：“主库上那个相同的DDL、DML也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。
所以，为了减少从库的延时，我们需要平时做好以下维护：
a)尽量让主库的dml或者ddl快速执行，如提高insert的效率（方法见上）；
b） 为了安全，有人可能会将主库的sync_binlog设置为1，innodb_flush_log_at_trx_commit也设置为1之类的，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0，来提高从库sql的执行效率。
（备注：sync_binlog是控制binlog_cache刷新到磁盘binlog频率的，而innodb_flush_log_at_trx_commit是控制redo log buffer刷新到磁盘redolog频率的。sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。所以sync_binlog=1保证了数据安全，但是性能最差。）
c）使用比主库更好的硬件设备作为slave
d) 使用mysql 5.6新参数 slave_parallel_workers ，使从库多线程，不过，slave_parallel_workers只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master，需要想办法进行优化。
e）升级Mysql到5.7，因为mysql 5.7支持真正意义的从库多线程了，即主库多少线程，从库也多少线程。mysql 5.7号称主从复制永不丢数据（一直没时间试用过）。
5. 有没有用GTID,对GTID了解吗？
答：用过GTID。曾经民航局的一个项目就用的是GTID。
GTID是mysql 5.6的新东西，用事务提交号替换binlog的位置号。不过GTID这个东西在5.6还是有很多局限性的，个人不建议用。
GTID的全称为 global transaction identifier ， 可以翻译为全局事务标示符。
GTID由两部分组成：GTID = source_id:transaction_id
source_id用于标示源服务器，用server_uuid来表示，这个值在第一次启动时生成，并写入到配置文件data/auto.cnf中
transaction_id则是根据在源服务器上第几个提交的事务来确定。
6. Innodb是行锁，那什么时候会产生行锁，什么情况下会变成表锁？
答：一般情况下，innodb只对指定的行进行锁定，其他进程还是可以对表中的其他行进行操作的，因此，这时候innodb加的就是行锁；
但是，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”。
7. 使用过其他分支版本的数据库吗？percona,mariadb等。对percona的pxc集群了解吗？
答：除了oracle旗下的MySQL外，我还使用过percona server。percona是在源生mysql的基础上，进行了优化和改进，所以percona的性能比mysql更好。目前，我知道percona提供免费的线程池功能，而社区版的mysql没有线程池的功能（当然，企业版的mysql是有线程池的，但是需要收费）；另外percona还支持NUMA等功能。
我熟悉pxc，我曾经在测试环境搭建过pxc，但是没有在生产上使用，因为目前使用pxc的企业不是很多，目前我知道搜狐在用pxc。
pxc是摒弃mysql主从的概念，即对于pxc来说，每个节点都可以读写，并且写一份数据，其他节点会同时拥有，这是一种同步的复制方案（区别于Mysql主从的异步复制）
8. 除了mysql，还了解过其他数据库吗？oracle，redis，mongodb等。
答：除了mysql，我还熟悉oracle，对oracle有两年的使用经验。
不过，我对redis和mongodb没有接触过，如果工作需要，我会学习他们。
9. 工作中遇到的最大的问题以及做的最好的工作？
答：自由发挥
10. 分库分表有没有用到，怎么实现的？
答：目前，根据我们的业务量，还没有使用分库分表。但是我有在关注MySQL的分布式方案，以前mysql分布式比较常用的方法是用阿里巴巴的cobar，将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分，或将不同的表放入不同的库，但是后来发现cobar有一个问题一直不能很好的解决。目前，我关注到有很多人用mycat替换了cobar。
11. 新创建的数据库，需要调整哪些参数？
答：调整两方面的参数，即调整操作系统的和数据库my.cnf的：
a)操作系统的参数
linux参数系统的默认参数很多都是很保守的，所以需要根据服务器性能将一些参数进行加大，如我会调整nofile（最大文件句柄数）和nproc（最大线程数），将其放到最大；我会将vm.swappiness设置为0，表示最大限度使用物理内存，然后才是 swap空间；我会将net.ipv4.tcp_tw_reuse 设置为1，表示将netstat中出现的TIME-WAIT状态的sockets重用到新的TCP连接上...等等
b）数据库的参数
对于mysql来说，my.cnf的参数调整非常重要，如果采用默认值，那么是很难发挥mysql性能的。一般我会特别关注innodb_buffer_pool这个值，该值一般设置为物理内存的70%,这样就可以把mysql的表和索引最大限度的load到内存中，从而使mysql数据库性能得到大的提升；另外，我还特别关注sync_binlog和innodb_flush_log_at_trx_commit这两个值的设置，具体含义见上；还有max_user_connections ，我一般将该值设置为2000；还有innodb_lock_wait_timeout，看程序是长连接还是短连接，一般我会设置为60秒；还有innodb_log_file_size ，这个值也设置的大一点，我一般设置的为500M或1G。
12. mysql的权限怎么管理？
答：只给insert,update，select和delete四个权限即可。有时候delete都不给。
13. 有开发基础吗？
答：没有
14. 如果发现CPU，或者IO压力很大，怎么定位问题？
答：
1、首先我会用top命令和iostat命令，定位是什么进程在占用cpu和磁盘io；
2、如果是mysql的问题，我会登录到数据库，通过show full processlist命令，看现在数据库在执行什么sql语句，是否有语句长时间执行使数据库卡住；
3、执行show innodb engine status命令，查看数据库是否有锁资源争用；
4、查看mysql慢查询日志，看是否有慢sql；
5、找到引起数据库占用资源高的语句，进行优化，该建索引的建索引，索引不合适的删索引，或者根据情况kill掉耗费资源的sql语句等