1.非聚簇索引一定会回表查询吗?
不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。
举个简单的例子：假设我们在员工表的年龄上建立了索引,那么当进行的查询时,在索引的叶子节点上,已经包含了age信息,不会再次进行回表查询.
select age from employee where age < 20
2.Mysql删除表几种方式?有什么区别?
delete : 仅删除表数据，支持where条件过滤，支持回滚。记录日志。因此比较慢。delete from links;
truncate: 仅删除所有数据，不支持where条件过滤，不支持回滚。不记录日志，效率高于delete。truncate table links;
drop:删除表数据同时删除表结构。将表所占的空间都释放掉。删除效率最高。drop table links;
3.MySQL自增id不连续问题?
唯一键冲突 假设执行 SQL 的时候 user 表 id = 10，此时在内存中的自增 id 为11，此时发生唯一键冲突写库失败，则 user 表没有 id = 10 这条记录，之后 id 从11开始写入，因此 id 是不连续的。
事务回滚 假设同时需要对 user、staff 表进行写库操作，执行 SQL 的时候 user 表 id = 10，此时在内存中的自增 id 为11;staff 表 id = 20，此时内存中的自增 id 为21，一旦事务执行失败，事务回滚，写库失败，则 user 表没有 id = 10 这条记录，staff 表没有 id = 20 这条记录，user 表从11开始写入，staff 表从21开始写入，如此产生 id 不连续的现象。
批量写库操作 对于批量插入数据的语句，MySQL 有一个批量申请自增 id 的策略： 1. 语句执行过程中，第一次申请自增 id，会分配 1 个;
2. 1 个用完以后，这个语句第二次申请自增 id，会分配 2 个; 3. 2 个用完以后，还是这个语句，第三次申请自增 id，会分配 4 个; 依此类推，同一个语句去申请自增 id，每次申请到的自增 id 个数都是上一次的两倍。 假设批量往 user 表中写入四条记录，则这四条记录将分为三次申请id， 第一次分配到 id = 1，第二次分配到 id = 2、3 ，第三次分配到 id = 4、5、6、7，当批量写入四条记录之后，id = 1、2、3、4将会入库，但是 id = 5、6、7就被废弃了，下一个 id 从8开始。
4.选择合适的存储引擎?
在选择存储引擎时，应根据应用特点选择合适的存储引擎，对于复杂的应用系统可以根据实际情况选择多种存储引擎进行组合。
下面是常用存储引擎的适用环境。
MyISAM：5.1及之前版本默认存储引擎。如果应用是以读操作和插入操作为主，=只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存 储引擎是非常适合的。MyISAM 是在 Web、数据仓储和其他应用环境下最常使用的存储引擎 之一。
InnoDB：5.5及之后默认存储引擎。用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询以外，还包括很多的更新、 删除操作，那么 InnoDB 存储引擎应该是比较合适的选择。InnoDB 存储引擎除了有效地降低 由于删除和更新导致的锁定，还可以确保事务的完整提交(Commit)和回滚(Rollback)， 对于类似计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB 都是合适的选 择。
MEMORY：将所有数据保存在 RAM 中，在需要快速定位记录和其他类似数据的环境 下，可提供极快的访问。MEMORY 的缺陷是对表的大小有限制，太大的表无法 CACHE 在内存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。MEMORY 表通常用于更新不太频繁的小表，用以快速得到访问结果。
MERGE：用于将一系列等同的 MyISAM 表以逻辑方式组合在一起，并作为一个对象引用它们。MERGE 表的优点在于可以突破对单个 MyISAM 表大小的限制，并且通过将不同 的表分布在多个磁盘上，可以有效地改善MERGE表的访问效率。这对于诸如数据仓储等VLDB 环境十分适合。
5.选择合适的数据类型?
前提: 使用适合存储引擎。
选择原则,根据选定的存储引擎,确定如何选择合适的数据类型,下面的选择方法按存储引擎分类 :
MyISAM 数据存储引擎和数据列
MyISAM数据表，最好使用固定长度的数据列代替可变长度的数据列。