java面试题核心篇（一）

数据存储

1、索引使用的注意事项

（1）索引应该建在选择性高的字段上（键值唯一的记录数/总记录条数），选择性越高索引的效果越好、价值越大，唯一索引的选择性最高。
（2）组合索引中字段的顺序，选择性越高的字段排在最前面。
（3）where条件中包含两个选择性高的字段时，可以考虑分别创建索引，引擎会同时使用两个索引（在OR条件下，应该说必须分开建索引）。
（4）索引不会包含有null值的列，只要列中包含null，都将不会被包含到索引中，符合索引只要有一列含有null值，那么这列对于符合索引就是无效的。
（5）不要在列上进行运算。
（6）使用短索引，对字符串列进行索引，如果可以就应该指定一个前缀长度，如果有一个char（255）的列，如果在前10个或20个字符内，多数值是唯一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
（7）like语句操作，一般情况下不鼓励使用like操作，如果非使用不可，注意正确的使用方式。like ‘%aaa%'不会使用索引，而like ‘aaa%'可以使用索引。
（8）不使用NOT IN 、<>、！=操作，但<,<=，=，>,>=,BETWEEN,IN是可以用到索引的。

2、说说反模式设计

反模式是指在对经常面对的问题经常使用的低效，不良，或者有待优化的设计模式/方法。甚至，反模式也可以是一种错误的开发思想/理念。在这里我举一个最简单的例子：在面向对象设计/编程中，有一条很重要的原则， 单一责任原则(Single responsibility principle)。其中心思想就是对于一个模块，或者一个类来说，这个模块或者这个类应该只对系统/软件的一个功能负责，而且该责任应该被该类完全封装起来。当开发人员需要修改系统的某个功能，这个模块/类是最主要的修改地方。相对应的一个反模式就是上帝类(God Class)，通常来说，这个类里面控制了很多其他的类，同时也依赖其他很多类。整个类不光负责自己的主要单一功能，而且还负责了其他很多功能，包括一些辅助功能。一个类里有几千行的代码，有很多功能，但是责任不明确单一。单元测试程序也变复杂无比。维护/修改这个类的时间要远远超出其他类的时间。

3、说说分库与分表设计

对于访问极为频繁且数据量巨大的单表来说，我们首先要做的就是减少单表的记录条数，以便减少数据查询所需要的时间，提高数据库的吞吐，这就是所谓的分表，分表能够解决单表数据量过大带来的查询效率下降的问题，但是，却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问，当数据库master服务器无法承载写操作压力时，不管如何扩展slave服务器，此时都没有意义了。因此，我们必须换一种思路，对数据库进行拆分，从而提高数据库写入能力，这就是所谓的分库。一般情况下，数据库划分的基本思路可以归纳为：基于业务垂直划分；基于数据水平拆分；或者复杂一点的场景就需要将两者综合应用。
垂直划分：基于领域模型做数据的垂直切分是一种最佳实践。如将订单、产品、账户、财务等领域模型划分到不同的DB库里面。且由于各领域数据之间join展示场景较少，在这种情况下分库能获得很高的价值，同时各个系统之间的扩展性得到很大程度的提高。
水平切分：对于一些大型的系统来说，垂直分库之后是远远不够的，还需要做数据的水平切分。

4、分库与分表带来的分布式困境与应对之策

分库分表维度问题
如果按照患者划分维度，则每个患者维度进行分表，则每个患者的就诊信息，都保存在同一张表中，所以可以很方便的查找到患者就诊信息，但是如果要统计一个月内医院就诊情况，则数据可能分布在多张表中。
表关联问题
在单库单表的情况下，联合查询是非常容易的。但是，随着分库与分表的演变，联合查询就遇到跨库关联和跨表关系问题。在设计之初就应该尽量避免联合查询，可以通过程序中进行拼装，或者通过反范式化设计进行规避。
分页与排序问题
列表分页时需要按照指定字段进行排序。在单库单表的情况下，分页和排序也是非常容易的。但是，随着分库与分表的演变，也会遇到跨库排序和跨表排序问题。为了最终结果的准确性，需要在不同的分表中将数据进行排序并返回，并将不同分表返回的结果集进行汇总和再次排序，最后再返回给用户。
分布式事务问题
随着分库与分表的演变，一定会遇到分布式事务问题，那么如何保证数据的一致性就成为一个必须面对的问题。目前，分布式事务并没有很好的解决方案，难以满足数据强一致性，一般情况下，使存储数据尽可能达到用户一致，保证系统经过一段较短的时间的自我恢复和修正，数据最终达到一致。
分布式全局唯一ID
在单库单表的情况下，直接使用数据库自增特性来生成主键ID，这样确实比较简单。在分库分表的环境中，数据分布在不同的分表上，不能再借助数据库自增长特性。

5、说说 SQL 优化之道

（1）创建必要的索引，创建索引给检索带来的性能提升往往是巨大的。
（2）使用预编译查询，参数化SQL不仅能够避免SQL注入，最重要的是数据库会对参数化SQL进行预编译，这样第一次执行的时候数据库会为这个SQL语句进行查询优化并且执行预编译，以后再执行这个SQL时会直接使用预编译的结果，这样会大大提高执行速度。
（3）调整where语句中的连接顺序，数据库一般采用自下而上的顺序解析SQL，根据这个原理表连接最好写在其where条件之前，这样可以过滤最大数量的记录。
（4）尽量将多条SQL压缩到一条SQL执行。
（5）用where替代having，因为HAVING只会在检索出所有记录之后才对结果集进行过滤，而where则是在聚合前刷选记录，如果能通过where字句限制记录的数目，那就能减少这方面的开销。HAVING中的条件一般用于聚合函数的过滤，除此之外，应该将条件写在where字句中。
（6）使用表的别名，使用表的别名并把别名前缀于每个列名上。这样就可以减少解析的时间并减少哪些列名歧义引起的语法错误。
（7）在in和exists中通常情况下使用EXISTS，因为in不走索引。
（8）避免在索引上使用计算，如果索引列是计算或者函数的一部分，DBMS的优化器将不会使用索引而使用全表查询。
（9）使用unionall替换union，当SQL语句需要union两个查询结果集合时，即使检索结果中不会有重复的记录，如果使用union这两个结果集同样会尝试进行合并，然后在输出最终结果前进行排序，因此如果可以判断检索结果中不会有重复的记录时候，应该用union all，这样效率就会因此得到提高。 
（10）避免SQL中出现隐式类型转换，当某一张表中的索引字段在作为where条件的时候，如果进行了隐式类型转换，则此索引字段将会不被识别，因为隐式类型转换也属于计算，所以此时DBMS会使用全表扫面。
（11）防止索引检索范围过宽， 如果DBMS优化器认为检索范围过宽，那么将放弃索引查找而使用全表扫描，下面可能会造成索引检索过宽：1.使用is not null或者不等于判断，可能造成优化器假设匹配的记录数太多；2.使用like运算符的时候，“a%”将会使用索引，而“a%c”和“%a”则会使用全表扫描。

6、MySQL 遇到的死锁问题

死锁是指两个或两个以上的进程在执行的过程中，因争夺资源而造成的互相等待的现象，死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。常见导致死锁的场景：
1.例如两个用户同时投资，A用户金额随机分为2份，分给借款人1，2，B用户金额随机分为2份，分给借款人2，1，由于加锁的顺序不一样，死锁很快就出现了。对于这个问题的改进很简单，直接把所有分配到的借款人直接一次锁住就行了。Select * from xxx where id in (xx,xx,xx) for update 在in里面的列表值mysql是会自动从小到大排序，加锁也是一条条从小到大加的锁
2.根据字段值查询（有索引），如果不存在，则插入；否则更新，当对存在的行进行锁的时候(主键)，mysql就只有行锁。当对未存在的行进行锁的时候(即使条件为主键)，mysql是会锁住一段范围（有gap锁）。锁住的范围为：(无穷小或小于表中锁住id的最大值，无穷大或大于表中锁住id的最小值)，对于这种死锁的解决办法是：insert into t3(xx,xx) on duplicate key update `xx`='XX';用mysql特有的语法来解决此问题。因为insert语句对于主键来说，插入的行不管有没有存在，都会只有行锁。

7、存储引擎的 InnoDB 与 MyISAM

（1）存储结构：MyISAM每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。.frm文件存储表定义。数据文件的扩展名为.MYD(MYData)。索引文件的扩展名是.MYI (MYIndex)。InnoDB所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB。
（2）存储空间：MyISAM可被压缩，存储空间较小。支持三种不同的存储格式：静态表(默认，但是注意数据末尾不能有空格，会被去掉)、动态表、压缩表。InnoDB需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。
（3）可移植性、备份及恢复：MyISAM数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作。InnoDB免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了。
（4）事务支持：MyISAM强调的是性能，每次查询具有原子性,其执行数度比InnoDB类型更快，但是不提供事务支持。InnoDB提供事务支持事务，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
（5）自增列：MyISAM可以和其他字段一起建立联合索引。引擎的自动增长列必须是索引，如果是组合索引，自动增长可以不是第一列。InnoDB中必须包含只有该字段的索引。引擎的自动增长列必须是索引，如果是组合索引也必须是组合索引的第一列。
（6）表锁差异：MyISAM只支持表级锁，InnoDB支持事务和行级锁，是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁，只是在WHERE的主键是有效的，非主键的WHERE都会锁全表的。
（7）全文索引：MyISAM支持 FULLTEXT类型的全文索引InnoDB：不支持FULLTEXT类型的全文索引，但是innodb可以使用sphinx插件支持全文索引，并且效果更好。
（8）表主键：MyISAM允许没有任何索引和主键的表存在，索引都是保存行的地址。InnoDB如果没有设定主键或者非空唯一索引，就会自动生成一个6字节的主键(用户不可见)，数据是主索引的一部分，附加索引保存的是主索引的值。
（9）表的具体行数：MyISAM保存有表的总行数，如果select count(*) from table;会直接取出出该值。InnoDB没有保存表的总行数，如果使用select count(*) from table；就会遍历整个表，消耗相当大，但是在加了wehre条件后，myisam和innodb处理的方式都一样。
（10）CURD操作：MyISAM如果执行大量的SELECT，MyISAM是更好的选择。InnoDB如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表。DELETE 从性能上InnoDB更优，但DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除，在innodb上如果要清空保存有大量数据的表，最好使用truncate table这个命令。
（11）外键：MyISAM：不支持，InnoDB：支持。

8、为什么要用 B-tree（参考http://blog.csdn.net/v_JULY_v/article/details/6530142）

大规模的数据存储中，树节点存储的元素数量是有限的（如果元素非常多，查找就会变成节点内部的线性查找），也就是说树的深度过大会造成磁盘I/O读写过于频繁，进而导致查询效率低下。B树中的每个结点根据实际情况可以包含大量的关键字信息和分支(当然是不能超过磁盘块的大小，根据磁盘驱动(disk drives)的不同，一般块的大小在1k~4k左右)；这样树的深度降低了，这就意味着查找一个元素只要很少结点从外存磁盘中读入内存，很快访问到要查找的数据。

9、数据库索引的原理

数据库索引的特点是避免进行数据库全表扫描，大多数情况，只需要扫描较少的索引页和数据页，而不是查询所有的数据页，而且对于非聚合索引，有时不需要访问数据页就可以得到数据。数据库通常将平衡树作为默认的索引数据结构，建表的时候都会为表加上主键，这样的话整个表就变成一个索引，也就是聚集索引，主键的作用就是将表数据转换成平衡树的格式放置。非聚集索引和聚集索引一样，同样是采用平衡树作为索引的数据结构。索引树结构中各节点的值来自于表中的索引字段。
索引能让数据库查询数据的速度上升，而使写入数据的速度下降，原因很简单的，因为平衡树这个结构必须一直维持在一个正确的状态， 增删改数据都会改变平衡树各节点中的索引数据内容，破坏树结构， 因此，在每次数据改变时，DBMS必须去重新梳理树（索引）的结构以确保它的正确，这会带来不小的性能开销，也就是为什么索引会给查询以外的操作带来副作用的原因。

10、聚集索引与非聚集索引的区别

聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个；
聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续。
聚集索引和非聚集索引问题归纳：
聚集索引的约束是唯一性，是否要求字段也是唯一的呢？
分析：如果认为是的朋友，可能是受系统默认设置的影响，一般我们指定一个表的主键，如果这个表之前没有聚集索引，同时建立主键时候没有强制指定使用非聚集索引，SQL会默认在此字段上创建一个聚集索引，而主键都是唯一的，所以理所当然的认为创建聚集索引的字段也需要唯一。
　　结论：聚集索引可以创建在任何一列你想创建的字段上，这是从理论上讲，实际情况并不能随便指定，否则在性能上会是恶梦。
为什么聚集索引可以创建在任何一列上，如果此表没有主键约束，即有可能存在重复行数据呢？
粗一看，这还真是和聚集索引的约束相背，但实际情况真可以创建聚集索引。分析其原因是：如果未使用 UNIQUE 属性创建聚集索引，数据库引擎将向表自动添加一个四字节 uniqueifier 列。必要时，数据库引擎 将向行自动添加一个 uniqueifier 值，使每个键唯一。此列和列值供内部使用，用户不能查看或访问。
是不是聚集索引就一定要比非聚集索引性能优呢？
如果想查询学分在60-90之间的学生的学分以及姓名，在学分上创建聚集索引是否是最优的呢？
　　答：否。既然只输出两列，我们可以在学分以及学生姓名上创建联合非聚集索引，此时的索引就形成了覆盖索引，即索引所存储的内容就是最终输出的数据，这种索引在比以学分为聚集索引做查询性能更好。
在数据库中通过什么描述聚集索引与非聚集索引的？
索引是通过二叉树的形式进行描述的，我们可以这样区分聚集与非聚集索引的区别：聚集索引的叶节点就是最终的数据节点，而非聚集索引的叶节仍然是索引节点，但它有一个指向最终数据的指针。
在主键是创建聚集索引的表在数据插入上为什么比主键上创建非聚集索引表速度要慢？
在有主键的表中插入数据行，由于有主键唯一性的约束，所以需要保证插入的数据没有重复。聚集索引由于索引叶节点就是数据页，所以如果想检查主键的唯一性，需要遍历所有数据节点才行，但非聚集索引不同，由于非聚集索引上已经包含了主键值，所以查找主键唯一性，只需要遍历所有的索引页就行，这比遍历所有数据行减少了不少IO消耗。这就是为什么主键上创建非聚集索引比主键上创建聚集索引在插入数据时要快的真正原因。

11、limit 20000 加载很慢怎么解决

当一个数据库表过于庞大，LIMIT offset, length中的offset值过大，则SQL查询语句会非常缓慢，你需增加order by，并且order by字段需要建立索引。如果对于有where 条件，又想走索引用limit的，必须设计一个索引，将where 放第一位，limit用到的主键放第2位，而且只能select 主键！

12、选择合适的分布式主键方案

最简单的方法是MySQL主键自增长，若有四台数据库，第一台主键从1开始每次加4，第二台从2开始每次开始加4，以此类推。单独开一个数据库，获取全局唯一的自增序列号或各表的MaxId。