中信梧桐港二面、公安部第一研究所

1.中信梧桐港二面

1.1 除了SQL提高数据查询优化，还有什么Java层面的优化？

　　缓存，消息队列异步化（当时竟然没想到，自己还做过）

1.2 字段索引失效

1. 频繁增删改的字段
2. 不是where的字段
3. 数据太少的表
4. 增删改多的表

 2.公安部第一研究所

2.1 G1收集器的特点：

1. 实时的垃圾回收
2. 区域化管理
3. 并发标记
4. 缺点：大量小对象回收时不如其他回收器

2.2 OMM的排查方法

　　OMM即Out of Memory（内存耗尽）。JVM无空间为对象分配内存，垃圾回收器无可回收内存时报错。

    2.2.1 出现OMM的原因：

1. 内存溢出：JVM初始内存小，业务使用大量内存；JVM区域分配内存不合理
2.  内存漏洞：某一对象被频繁使用，使用完后未被释放，导致内存耗尽（如ThreadLocal未在使用remove方法）

    2.2.2 常见的OOM

1. 方法区溢出：存储虚拟机加载的类信息、常量、静态变量，即编译器编译后的代码。大量Class对象、JSP页面或CGLIB动态代理导致；可通过-XX：PermSize 和 -XX：MaxPermSize 修改方法区大小
2. 虚拟栈溢出：死循环、深度递归或栈设置太小，可通过-XX：PermSize 和 -XX：MaxPermSize 修改方法区大小。可通过日志定位错误的类、方法
3. 堆内存溢出：堆内存设置不合理，堆内存溢出（可通过工具查看对象到GC Root的引用链）

    2.2.3 堆溢出排查方法

1. 查看内存分布：jmap -heap PID（查看JVM内存分配以及运行情况）
2. 查看最耗费资源对象：jmap -histo:live PID | more
3. Dump文件分析：Dump文件是Java内存的镜像。存储系统信息、虚拟机属性、完整的线程 Dump、所有类和对象的状态 等信息

    2.2.4 JVM 启动参数配置添加以下参数

• -XX:+HeapDumpOnOutOfMemoryError

• -XX:HeapDumpPath=./（参数为 Dump 文件生成路径）

    2.2.5 在JVM运行时导出

　　jmap -dump:file=[文件路径] [pid]
　　jmap -dump:file=./jvmdump.hprof 15162

    2.2.6 使用工具：JvisualVM

3. SQL优化

    3.1 Mysql优化原则

1. 减少数据访问：设置合理的字段类型，启用压缩，通过索引访问减少磁盘IO
2. 返回更少的数据：只返回需要的字段和数据分页处理，减少磁盘IO以及网络IO
3. 减少交互次数：批量DML操作，函数存储等减少数据连接次数
4. 减少服务器开销：尽量减少数据库排序操作以及全表查询，减少CPU内存占用
5. 利用更多资源：使用表分区，增加并行操作，更大限度使用CPU资源

    3.2 SQL优化

1. 最大化利用索引
2. 尽可能避免全表扫描：开头模糊查询（右模糊，一定要用：大数据es、几千条全模糊），In和not In（数值，between on、子查询exists），or（union），null判断（字段默认0），左侧表达式、函数操作（表达式函数移到右侧），大数据时不使用where1=1、<>或!=、联合索引最左匹配、类型转换、where与order by条件不一致
3. 减少无效数据查询
4. 其他优化：避免select * 、避免不确定结果函数、多表关联，小表前大表后（Mysql从左到右，第一张表全表查，Oracle相反）、使用类别名（减少解析）、避免having（检索所有记录再过滤）、where字句顺序（Mysql从左至右，自上到下解析where子句，可将过滤数据多的条件往前方，最快缩小结果集）。
5. 查询条件优化：如果分组不要求排序，则使用order by null，join优化，合理分页
6. 建表优化：有现在where、order by使用的字段建立索引，尽量使用数字类型字段（男：1，女：0）、大数据，使用分段分页查询、使用varchar/nvarchar代替char/nchar

3.3 select执行顺序：from on join where group by having select distinct order by limit