比较冷门但是偏底层

1,private static final long serialVersionUID=...是干什么的

1. 修改了此类,要修改这个值,用以前老版本得嘞序列化的类恢复时会出错,
2. 为了反序列化时确保类版本的兼容性,具体数值自己定义
3. 上边的忽略看下边的正解:
   1. 主要用于序列化和反序列化时之间的转换
   2. 用于版本控制
   3. 序列化后的文件存在网络中或者磁盘中都是可以被改写的,更改了类之后SUID就会发生改变不会反序列化为原来的类,还会抛异常
      1. java.io.InvalidClassException 异常

 2,mybatis字段和mysql关键字冲突:

1. 错误：DELETE = #{delete}
2. 正确：`DELETE` = #{delete}
3. index改为index
4. column
5. right

3,影响mysql数据性能的因素:

借鉴的博客:

https://www.cnblogs.com/sui776265233/p/9787509.html

https://blog.csdn.net/kqqkqq123/article/details/100192124

1,影响数据库的因素:

1.  sql查询速度
   1. 超高的QPS和TPS
      1. TPS(Transactions Per Second):每秒传输的事务处理个数
      2. QPS:每秒查询的处理个数
      3. 效率低下的sql,QPS
      4. 大量的并发和超高的CPU使用率
2. 磁盘IO:
   1. 随着并发数的增加,磁盘IO效率也会下降,主要是因为每次读写,刺刀可能存在较大的偏移,刺刀寻址时间加大,
      1. 导致磁盘IO性能几句下降
   2. 跟磁盘本身也有关系,
      1. 磁盘的缓存区
      2. 磁盘的读写速度
3. 网卡的流量:
   1. 网络的带宽也会影响mysql的性能
      1. 主要是影响利用率,影响了通吐量
4. 服务器硬件:
5. 单表存储大量的数据:
   1. 也会影响数据库的性能,
   2. 数据量大,检索的效率降低
6. 大事务:
   1. 处理一个比较复杂的业务关系的时候,增加或者删除修改该属性的时候都会影响mysql的性能
   2. 锁表的时间加长,产生问题回滚事务的时间加长,添加数据的时候时间加长都会造成巨大的延迟

2,如何进行优化:

1. 表的字段选取适当:
   1. 能用char(具体大小),就不要用varchar,选取比较适中的大小
   2. 能用mediumint就不要用bigin来定义整型字段
   3. 尽量把字段设置为Not Null,这样在执行查询的时候不会比较null的值
   4. 对于性别类似的能用数值类型就不要用varchar.
2. 使用(join)来代替子查询

   1. 子表:  SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
      表连接:  SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL

   2. 表连接查询效率高在于不需要创建零时表来完成逻辑,一步完成,子查询需要两步
3. 使用联合(UNION)来代替手动创建的临时表

   1. SELECT id , phone FROM `user` UNION SELECT `name`,age FROM t_employee 
      UNION SELECT username,`password` FROM t_buser

   2. 结果:
   3. 查询的结果以第一个字段的显示为主,将其他的数据合并到一起,主要是字段要一致
   4. 查询结束后会自动删除,保证数据库正解高效.
4. 事务:
   1. 进行分库分表,不同的业务对应不同的事务,避免出现锁表的情况导致占用数据库资源
   2. 查询的时候也比较方便
   3. https://www.cnblogs.com/butterfly100/p/9034281.html [数据库分库分表的思路]  #重要#
5. 使用外键:
   1. 尽量避免外键的使用,也会造成死锁问题,
   2. 也会消耗数据库检索和验证
6. 使用索引:
   1. 在做函数运算和排序的时候比较明显,
   2. 建立索引:
      1. 一般建立在Join,where 和 order by的字段是哪个
      2. 尽量不要在大量不要在大量重复复的值的字段建立索引

      3. 全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。

7. 业务逻辑的划分:
   1. 可以将部分逻辑的计算交给数据库来完成
   2. 类似于count()这样的函数,避免传输大量的数据消耗数据库的性能
   3. https://segmentfault.com/q/1010000002619005  [业务逻辑卸载数据库还是在应用程序中]
8. 优化查询语句:
   1. 在建立索引的字段尽量不要使用幻术进行操作
   2. 例如:  

      在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。
      
      　　SELECT * FROM order WHERE YEAR(OrderDate)<2001;
      SELECT * FROM order WHERE OrderDate<"2001-01-01";
      
      　　同样的情形也会发生在对数值型字段进行计算的时候：
      
      　　SELECT * FROM inventory WHERE Amount/7<24;
      SELECT * FROM inventory WHERE Amount<24*7;

   3. 搜索的时候尽量不要使用like和通配符
   4. 例如:

      　　SELECT * FROM books
      WHERE name like "MySQL%"
      
      　　但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：
      
      　　SELECT * FROM books
      WHERE name>="MySQL"and name<"MySQM"
      
      　　最后，应该注意避免在查询中让MySQL进行自动类型转换，因为转换过程也会使索引变得不起作用。

       
9. 略