比较冷门但是偏底层

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. 1 子表:  SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
      2 表连接:  SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL
      点击查看
    2. 表连接查询效率高在于不需要创建零时表来完成逻辑,一步完成,子查询需要两步
  3. 使用联合(UNION)来代替手动创建的临时表
    1. 1 SELECT id , phone FROM `user` UNION SELECT `name`,age FROM t_employee 
      2 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. 1 全文索引在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;
      View Code
    3. 搜索的时候尽量不要使用like和通配符
    4. 例如:
      1   SELECT * FROM books
      2 WHERE name like "MySQL%"
      3 
      4   但是如果换用下面的查询,返回的结果一样,但速度就要快上很多:
      5 
      6   SELECT * FROM books
      7 WHERE name>="MySQL"and name<"MySQM"
      8 
      9   最后,应该注意避免在查询中让MySQL进行自动类型转换,因为转换过程也会使索引变得不起作用。
      点击查看 

  9.  

     

 

 

 

 

 

 

 

posted @ 2019-11-21 13:15  简悦Pro  阅读(175)  评论(0编辑  收藏  举报