1、 对于查询频率高的字段创建索引； 2、 对排序、分组、联合查询频率高的字段创建索引； 3、 索引的数目不宜太多 原因： a、每创建一个索引都会占用相应的物理控件； b、过多的索引会导致insert、update、delete语句的执行效率降低； 4、若在实际中，需要将多个列设置索引时，可以采用多列索引 如：某个表(假设表名为Student)，存在多个字段(StudentNo, StudentName, Sex, Address, Phone,BirthDate)，其中需要对StudentNo,StudentName字段进行查询，对Sex字段进行分组，对BirthDate 字段进 行排序，此时可以创建多列索引index index_name (StudentNo, StudentName, Sex, BirthDate);#index_name为索 引名 在上面的语句中只创建了一个索引，但是对4个字段都赋予了索引的功能。 创建多列索引，需要遵循BTree类型，即第一列使用时，才启用索引。 在上面的创建语句中，只有mysql语句在使用到StudentNo字段时，索引才会被启用。 如: select * from Student where StudentNo = 1000; #使用到了StudentNo字段，索引被启用。 以使用explain检测索引是否被启用如:explain select * from Student where StudentNo = 1000; 5、选择唯一性索引 唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。例如，学生表中学号是具有唯 一性的字 段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话，可能存 在同名现象， 从而降低查询速度。 6、尽量使用数据量少的索引 如果索引的值很长，那么查询的速度会受到影响。例如，对一个CHAR(100)类型的字段进行全文检索 需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。 7、尽量使用前缀来索引 如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检 索会很浪费时 间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。 8、删除不再使用或者很少使用的索引. 表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理 员应当定期 找出这些索引，将它们删除，从而减少索引对更新操作的影响B+ tree树索引, B tree,散列

InnoDB: 事务型存储引擎, 并且有较高的并发读取频率 MEMORY： 存储引擎，存放在内存中，数据量小， 速度快 Merge: ARCHIVE： 归档， 有很好的压缩机制

1. 分库分表： 同样量的数据平均存储在不同数据库相同表（或不同表）中，减轻单表压力，如果还是很大，就可 以每个库在分多张表，根据hash取值或者其他逻辑判断将数据存储在哪张表中 2. 读写分离： 数据库原本就有主从数据库之分，查询在从服务器，增删改在主服务器， 3. 归档和操作表区分： 建一张归档表，将历史数据放入，需要操作的表数据单独存储 4. 索引啊之类的创建，对于数据量很大，百万级别以上的单表，如果增删改操作不频繁的话， 可以创建bitMap索引，速度要快得多 1. 共享锁：要等第一个人操作完，释放锁，才能操作 2. 更新锁：解决死锁，别人可以读，但不能操作 3. 排他锁：读写都被禁用 4. 意向锁（xlock）： 对表中部分数据加锁，查询时，可以跳过 5. 计划锁： 操作时，别的表连接不了这张表，

原子性： 所有操作要么全部成功，要么全部失败 一致性： 例如转账，一个事务执行前和执行后必须一致 隔离性： 防止脏读， 重复读问题 持久性： 永久性提交数据库

Concat: 字符串拼接， 或者 || MConcat: 字符串拼接， 或者 || Instr: 指定字符串位置 Length: 长度 Trim: 去空格 Lower: 小写 Upper:大写 Nvl: 判断空 Replace: 替换 Substr: 截取 Floor: 向下取整 To_number: To_char: To_date: Decode: 判断函数等等

1. 查询谓词没有使用索引的主要边界,换句话说就是select *，可能会导致不走索引 2. 单键值的b树索引列上存在null值，导致COUNT(*)不能走索引。索引列存在空值 3. 索引列上有函数运算，导致不走索引 4. 隐式类型转换导致不走索引。 5. 表的数据库小或者需要选择大部分数据，不走索引 6. ！=或者<>(不等于），可能导致不走索引 7. 表字段的属性导致不走索引，字符型的索引列会导致优化器认为需要扫描索引大部分数据且聚簇因子很大，最 终导致弃用索引扫描而改用全表扫描方式， 8. 使用like, in 等， 可能导致不走索引

确定ID存储用64位，1个64位二进制1是这样的00000000.....1100......0101，切割64位，某段二进制表示成1个约 束条件，前41位为毫秒时间，后紧接9位为IP，IP之后为自增的二进制，记录当前面位数相同情况下是第几个id，如 现在有10台机器，这个id生成器生成id极限是同台机器1ms内生成2的14次方个ID。 分布式唯一ID = 时间戳 << 41位， int类型服务器编号 << 10，序列自增sequence。每个时间戳内只能生成固定数 量如（10万）个自增号，达到最大值则同步等待下个时间戳，自增从0开始。将毫秒数放在最高位，保证生成的ID是 趋势递增的，每个业务线、每个机房、每个机器生成的ID都是不同的。如39bit毫秒数|4bit业务线|2bit机房|预留|7bit序列号。高位取2016年1月1日1到现在的毫秒数，系统运行10年，至少需要10年x365天x24小时x3600秒x1000 毫秒=320x10~9，差不多39bit给毫秒数，每秒单机高峰并发小于100，差不多7bit给每毫秒的自增号，5年内机房小 于100台机器，预留2bit给机房，每个机房小于100台机器，预留7bit给每个机房，业务线小于10个，预留4bit给业 务线标识。 64bit分布式ID（42bit毫秒+5bit机器ID+12位自增）等 生成分布式ID的方式：A，2个自增表，步长相互隔开 B，时间的毫秒或者纳秒 C，UUID D，64位约束条件（如上）

第一点，NIO少了1次从内核空间到用户空间的拷贝。 ByteBuffer.allocateDirect()分配的内存使用的是本机内存而不是Java堆上的内存，和网络或者磁盘交互都在操作 系统的内核空间中发生。allocateDirect()的区别在于这块内存不由java堆管理, 但仍然在同一用户进程内。 第二点，NIO以块处理数据，IO以流处理数据 第三点，非阻塞，NIO1个线程可以管理多个输入输出通道

LRU：从已设置过期时间的数据集合中挑选最近最少使用的数据淘汰 random：从已设置过期时间的数据中挑选任意数据淘汰 ttl：从已设置过期时间的数据集合中挑选将要过期的数据淘汰。 notenvision：禁止驱逐数据 如mysql中有2千万数据，redis只存储20万的热门数据。LRU或者TTL都满足热点数据读取较多，不太可能超时特点。 redis特点：速度块，O(1)，丰富的数据类型，支持事物原子性，可用于缓存，比memecache速度块，可以持久化数 据。 常见问题和解决：Master最好不做持久化如RDB快照和AOF日志文件；如果数据比较重要，某分slave开启AOF备份数 据，策略为每秒1次，为了主从复制速度及稳定，MS主从在同一局域网内；主从复制不要用图状结构，用单向链表更 为稳定 M-S-S-S-S。。。。；redis过期采用懒汉+定期，懒汉即get/set时候检查key是否过期，过期则删除key，定 期遍历每个DB，检查制定个数个key；结合服务器性能调节并发情况。 过期淘汰，数据写入redis会附带1个有效时间，这个有效时间内该数据被认为是正确的并不关心真实情况，例如对 支付等业务采用版本号实现，redis中每一份数据都维持1个版本号，DB中也维持1份，只有当redis的与DB中的版本 一致时，才会认为redis为有效的，不过仍然每次都要访问DB，只需要查询version版本字段即可。

10.请描述MyISM和InnoDB?

MyISM采用表级锁，对Myism表读不会阻塞读，会阻塞同表写，对Myism写则会阻塞读和写，即一个线程获得1个表的写锁后，只有持有锁的线程可以对表更新操作，其他线程的读和写都会等待。InnoDB，采用行级锁，支持事务，例如只对a列加索引，如果update...wherea=1andb=2其实也会锁整个表，select 使用共享锁，update insert delete采用排它锁，commit会把锁取消，当然select by id for update也可以制定排它锁。

内容篇幅较多，还有腾讯版面试题，可查看个人简介进群获取！