1. 如果select长时间不返回，使用show processlist查看当前语句处于什么状态
   • 比如MDL写锁阻塞了别的session的读
   • 可以查询是什么session阻塞，但是在MySQL启动时需要设置performance_schema = ON，这样会有10%的性能损失

• sys.schema_table_lock_waits，查询这张表可以找到导致阻塞的processid，kill掉即可

• 还有可能被flush阻塞了，一般flush的两个语句是flush table t with read lock锁表t，flush tables with read lock锁所有的表，本身刷脏页的速度很快，但是可能flush命令被别的session阻塞了

• 或者别的线程占用写锁，那么申请lock in share mode的读锁就会被阻塞。通过查找sys.innodb_lock_waits表即可

• 如果在RR场景下，或者在一个事务中，使用select，如果此时别的session有一个update语句，update了一百万次，那么自己的select语句就会特别慢，因为是一致性读，会存在非常大的undolog需要不断查找，而如果使用select in lock share mode，就是当前读，速度就会很快。

幻读

1. RR下，普通查询是快照读，幻读只有在当前读的环境下才会出现，因为快照读不会看到别人提交的数据。并且，如果别人修改了一行，在当前读的两次查询中，第二次查询才读到，那不是幻读。幻读只有是读到别人新插入的行

• 幻读会破坏加锁的语义，因为先对d=5的行加锁，在别的session中insert了一条d=5，a=1的行，并修改a=1的行将b改成2，这样的话，也就是修改了d=5的行，破坏了最初对d=5的行加锁的语义

• 幻读 + statement格式的binlog会导致数据不一致性，因为binlog是在commit的时候才会记录，

• 即便给所有的行都加上锁，也无法解决幻读的问题，因为原本不存在的行，无法加锁，所以即便给所有的行都加锁，也没有办法阻止插入新的行

• 所以需要加上间隙锁，在值和值的中间加锁，避免插入新的值

• 解决幻读，需要加行锁和间隙锁(gap lock，开区间)

• 行锁 + 间隙锁 = next-key lock (临键锁，左开右闭)

死锁

1. 如果对不存在的一行加锁，比如id=9，不存在
   select * from t where id = 9 for update
   • 那么本来应该加行锁+间隙锁，但是因为id=9不存在，所以只会加间隙锁
2. 本来select for update是两个排他锁，但是因为不存在这一行，所以两个session都可以对id=9这一行使用select for update，因为都是间隙锁，所以不会冲突
3. 此时session B判断不存在这一行，尝试添加id=9的记录，但是因为session A中有间隙锁，所以被阻塞
4. session A也判断不存在这一行，尝试添加id=9的记录，但是因为session B中存在间隙锁，所以被阻塞，导致死锁

• 所以RR会导致死锁，因为只有RR才有间隙锁，一般会设置为RC + row格式的binlog，这样可以解决死锁，并且不会出现数据日志不一致问题
• 一般在金融等，或者表备份的时候，才是RR

加锁

1. 加锁的基本单位是next-key lock，前开后闭
2. 查找中访问的对象才会加锁
3. 索引上等值查询，唯一索引的时候next-key lock 退化为行锁
4. 等值查询，最右边的值不满足等值查询的时候，退化为间隙锁
5. 唯一索引上范围查询会找到不满足条件的第一个值

现在一张表，字段是id，c, d，c上有普通索引，id是主键

• 内含数据(0, 0, 0)(5, 5, 5)(10, 10, 10)(15, 15, 15)(20, 20, 20)(25, 25, 25)

举例1 - 等值查询间隙锁

• 对于session A表中没有id=7的行，加锁单位是临键锁，前开后闭，所以范围是(5, 10]
• id=7是等值查询，找到最后边的值10，不满足等值条件，所以退化为间隙锁，加锁范围就是(5, 10)
• session B插入id=8就会被阻塞，但是session C插入id=10不会被锁

举例2 - 非唯一索引等值查询

• 加临键锁，对(0, 5]
• c是普通索引，所以会访问到右边第一个不满足的值为止，也就是查询到10， 所以(5, 10]加临键锁
• c=5是等值查询，最右边一个值10不满足等值条件，退化为间隙锁(5, 10)
• 访问到的对象才会加锁，覆盖索引不需要访问主键，所以主键索引不需要加锁，因此session B可以完成，session C插入(7, 7, 7)会被阻塞
• lock in share mode只会锁覆盖索引，但是for update会判断你要更新，就会给主键索引上满足条件加行锁

举例3 - 主键索引范围查询

• 先找到id = 10，next-key lock (5, 10]，但是唯一索引会退化为行锁
• 但是范围查找，找到id=15停止，所以会有临键锁(10, 15]
• 所以B插入(8, 8, 8)可以通过，插入(13, 13, 13)被阻塞；C更新15也被阻塞

举例4 - 非唯一索引范围查询

• 查找c = 10的时候，临键锁(5, 10]，不是唯一索引，不会退化为行锁
• session A加上了两个临键锁(5, 10]和(10, 15]
• B插入(8, 8, 8)阻塞

举例5 - 唯一索引范围查询bug

• A是范围查询，索引id加到(10, 15]临键锁，id是唯一索引，所以判断到id=15结束
• 但是会访问到第一个不满足条件的值为止，所以会找到id=20，范围查询，所以会加上(15, 20]的临键锁
• 因此B更新20会阻塞，C插入16也会阻塞

举例6 - 非唯一索引存在等值

比如同时有两行c=10，分别是(10, 10, 10)，和(30, 10, 30)

• 非唯一索引上包含主键值，所以不会重复

• A遍历找到第一个c=10的记录，所以临键锁加在(5 5, 10 10]上
• A向右查找，碰到第一个不满足条件的行，也就是15 15停止，等值查询，退化为10 10到15 15的行锁
• 所以最后是(5 5, 10 10]临键锁，(10 10, 15 15)行锁，因此B插入12会被阻止，C修改15会通过

举例7 - limit加锁

• 因为有limit 2，所以遍历到10 30后，就已经满足两条了，循环结束
• A加锁范围就是(5 5, 10 10]临键锁(10 10, 10 30]临键锁
• B插入12通过
• 所以删除的时候可以加limit，限制删除的条数，操作更安全。
  • 但是唯一索引上删除不需要，因为唯一索引本身就只加行锁
  • 可能更适合普通索引，但是数据是唯一的情况

举例8 - 死锁

• A在c上加了(5, 10]临键锁和(10, 15)间隙锁
• B要在c上加(5, 10]临键锁，所以等待A释放
• A 想插入8，需要加锁，等待B释放，死锁
• 最后B回滚
• B的临键锁没有申请成功，但是B加锁(5, 10]先加间隙锁，加锁成功，再加c=10的行锁，阻塞，两段执行

总结

• RR才有间隙锁，并且两阶段提交，事务commit了，锁释放
• RC没有间隙锁，并且语句执行完就会释放不满足条件的行的行锁
• RC在外键也会有间隙锁

优化

• show variables like '%connections%;查看max_connections，也就是最大连接数，超过最大连接数的就会被阻止，最大连接数不是越大越好。

1. 处理掉占用连接但是没有工作的线程
   • show variables like 'wait_timeout';查看超时时间，超过时间以后就会断开连接
   • 可以使用kill connection + id，但是这样客户端不会马上知道，只有在发起下一个请求以后才会报错，就变成了MySQL一直都没有恢复，但是再次 调用接口就可以访问了
2. 减少连接消耗
   • 用–skip-grant-tables跳过权限验证，但是风险极高，不建议使用，找回密码可以用
   • 8.0版本如果使用跳过权限验证，会同时--skip-networking打开这个，保证数据库只有本地访问
3. 性能问题导致短链接增加
   • 慢查询
     • 索引没设计好
       • 5.6版本后可以使用Online DDL创建索引，alert table即可
       • 如果一主一备，在从库处理，set sql_log_bin=off，不写binlog，加索引
       • 主备切换
       • 再在从库set sql_log_bin=off，加索引
     • 语句有问题
       • 使用存储过程query_rewrite重写某一个语句
     • 选错索引
       • 使用query_rewrite加上索引即可，或者语句加索引
     • 可以在上线前处理好，上线前将slow log打开，long_query_time=0记录查询语句
     • 测试表模拟线上数据，回归测试
     • 留意row_examined数据
     • 全量回归测试可以使用开源工具pt-query-digest
   • QPS暴增
     • 如果是全新业务有bug，下掉业务，数据库端去除白名单
     • 新功能是单独数据库用户，删除用户，断开现有连接
     • 如果和现有业务部署在一起，查询重写功能重写语句，压力最大的SQL直接select 1返回
       • 但是会有误伤，如果别的业务也用了这个SQL，或者这个语句还有别的用处，都会导致其他业务失败
   • 更新语句

数据更新

• binlog在事务执行时写入binlog cache，事务提交时写入binlog，清空cache

• binlog_cache_size控制cache大小，超过大小的暂时写入磁盘

• 多个线程有自己的binlog cache，但是共用一个binlog

• write是写入cache，速度快，fsync是写binlog文件，sync_binlog参数控制时机

  • sync_binlog = 0，每次提交只write，不fsync
  • sync_binlog = 1每次提交都会fsync
  • sync_binlog = N(N > 1)，每次都write，累计N个事务再fsync
  • IO非常大的话，可以适当调大这个值，100 - 1000，但是如果重启了，就会丢失N条binlog，如果容错率很低，不能设置为1

• redo log三种状态，分别是redo log buffer，write到page cache，没有持久化和fsync到磁盘，innodb_flush_log_at_trx_commit控制

  • = 0 表示每次都只保存再buffer中
  • = 1 表示每次提交都持久化到磁盘
  • = 2 表示每次提交都write到page cache
  • InnoDB后台线程每隔1s都会将redo log buffer中的内容write到pagecache再fsync到磁盘，所有的线程共用一个redo log buffer，与binlog不同，所以没有提交的事务的redo log，也有可能被持久化到磁盘
  • 同样，如果redo log buffer占用innodb_log_buffer_size即将到达一半，就会触发主动写盘，但是只write，没有fysnc
  • 如果并行事务，并且innodb_flush_log_at_trx_commit=1，那么别的事务提交的时候，会把自己没有提交的redo log 持久化到磁盘
  • 如果=1，那么prepare阶段就会持久化一次，所以只需要每隔1s的刷盘，崩溃恢复的逻辑，只需要binlog写入磁盘，redo log prepare write了，就不需要fsync了
  • 如果sync_binlog=1， innodb_flush_log_at_trx_commit=1，那么事务提交前，现需要等两次刷盘，一次是redo log的prepare，一次是binlog
  • 也就是如果MySQL``TPS两万，就会有四万次写磁盘，所以使用了组提交的方法减少写盘。

• 日志逻辑序列号是LSN，单调递增，对应redo log的写入点，写入长度为len，那么LSN + len，可以避免多次重复提交redo log

  • 比如三个事务同时在redo log buffer中，事务1写盘的时候，会带上事务23写盘，这样LSN之前的事务都完成了写盘，只需要看LSN后的事务即可
  • binlog也是有组提交，但是效果不如redo log，因为redo log时间较短，所以binlog等不到那么多

1. 设置binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count，满足一个即可，减少binlog的写盘次数，故意等待时间，跟sync_binlog不同，sync是没有写盘就commit事务，但是这两个参数是直到写盘了，才commit事务，会增加响应时间，但是不会像sync一样丢数据
   • innodb_flush_log_at_trx_commit不建议为0，这样redo log只会在内存中，宕机了会丢数据
   • innodb_flush_log_at_trx_commit设置成2，性能差不多，只有在主机关机才会丢数据，如果服务宕机，重启以后数据还在

• binlog不能中断，必须连续写，所以每个线程一个binlog cache，不然主从不一致；redo log甚至可以跟着别的线程一块写，所以都是一个redo log buffer

• 所以可以sync_binlog=1,innodb_flush_log_at_trx_commit=2,这样redo log如果丢失了，就通过binlog恢复就可以

• 一般设置非双一，就是innodb_flush_log_at_trx_commit=2、sync_binlog=1000

  • 业务高峰期，会有预案主库改写为非双1
  • 从库延迟，为了让从库赶上主库，减少binlog生成频率，赶上了可以改回来
  • 用备份恢复主库的副本，也就是使用binlog的时候
  • 批量导入数据也可以修改，不然binlog=row产生内容太多

• 主从首先保证了最终一致性，只要主库正确提交，就有binlog，那么从库正常就会重放binlog

• 主从延迟就是从库执行完的时间点-主库执行完的时间点

• 从库上执行show slave status，可以看到seconds_behind_master，表示延迟了多少

• 主从延迟最主要是从库消费relay log的速度比主库生成binlog的速度更慢

• 主从延迟来源

  • 从库性能比主库机器性能差(但是现在一般不会)
  • 从库压力大，CPU资源占用较多，导致重放relay log速度变慢
    • 一主多从，让多个从库分担压力
    • binlog输出到外部，比如Hadoop，让外部提供查询能力
  • 大事务，比如一个事务再主库上执行了十分钟，就延迟了十分钟
  • 大表上DDL

主从复制

1. 5.6版本之前，支持单线程，但是会导致应用日志较慢，造成延迟
2. 多线程就是拆sql thread为多个线程
   
   • 比如coordinator就是原来的sql thread，但是不更新了，只是负责读中转日志，并分发日志，work线程才更新日志，worker线程个数根据slave_parallel_workers决定，一般32核设置8-16即可，
   • coordinator分发规则：
     • 不能更新覆盖，同一行的两个事务必须在同一个worker中
     • 不能拆分事务，同一个事务必须在同一个worker中
3. 按表分发策略
   • 如果两个事务更新不同的表，就可以分发到不同的worker中
   • 如果事务跨表，需要将两张表一起考虑
   • 每个worker中对应一张hash表，保存当前worker中正在执行的事务里面涉及的表，值是多少个事务在更新这个表
   • 如果coordinator收到事务T，判断其中修改的表
     • 没有worker中包含这些表，那就分给最空闲的worker
     • 如果跟多于一个worker冲突，就等待
     • 如果只跟一个worker冲突，那就分给这个worker
   • 所以如果热点表，就变成了单线程，如果负载均衡，就很好解决问题
4. 按行分发策略
   • 需要binlog = row
   • 必须有主键，不能有外键
   • 但是对于大事务，耗费内存，耗费CPU资源更大
5. 5.6版本，按库分发并行
6. 5.7版本slave-parallel-type控制并行策略，配置为DATABASE就是按库并行，配置LOGICAL_CLOCK
   • 同处于prepare的事务，备库可以并行
   • 处于prepare和commit的事务可以并行

一主多从基本架构

1. 主库负责写入和一部分读，从库负责读
   切换主库的时候需要找同步位点，5.6版本使用GTID，全局事务ID，在事务提交时生成
   两个部分，格式为server_uuid:gno
   • server_uuid是实例启动产生的，全局唯一
   • gno是整数，初始值为1，每次提交事务的时候分配给这个事务，就加1
   • 启动GTID在启动时加上参数gtid_mode=on 和 enforce_gtid_consistency=on即可
     使用基于GTID的主备切换，就不需要指定位点，因为位点是不精确的。所以建议使用基于GTID的主从复制

主从延迟怎么解决

1. 强制走主库方案；

   • 比如交易平台，卖家发布商品以后，马上返回主页面，看商品是否发布成功，这个就强制走主库，因为需要拿到最新的结果
   • 如果是买家，晚几秒看到商品也可以接受，就走从库

2. sleep方案

   • sleep(1)大部分同步1s内能搞定，但是不太稳妥

3. 判断主备无延迟方案

   1. show slave status中的seconds_behind_master是否等于0
      • 单位是秒，如果精度不够，可以使用位点和GTID
   2. Master_Log_File和Read_Master_Log_Pos表示读到主库的最新位点
      Relay_Master_Log_File和Exec_Master_Log_Pos表示备库执行的最新位点
      如果Master_Log_File=Relay_Master_Log_File&&Read_Master_Log_Pos=Exec_Master_Log_Pos表示日志同步完成
   3. GTID中
      Auto_Position=1表示主备使用了GTID协议
      Retrieved_Gtid_Set是备库收到的所有日志GTID集合
      Executed_Gtid_Set是备库已经执行完的GTID集合
      如果两个集合相同，则日志同步完成
   4. 但是上面的方法是判断备库收到的binlog已经执行完了，但是实际上可能主库有binlog，但是备库还没有收到，这时需要使用半同步复制
   5. 业务高峰期，主库位点和GTID更新很快，位点判断就会一直不成立，那么从库就一直都无法响应

4. 配合semi-sync方案

   • 牺牲一定可用性，保持一致性
   • 但是因为半同步只要一个从库同步就返回ack，实际上请求可能打到别的没有同步的从库上
   • 所以半同步配合位点方案，会有问题
     • 一主多从，会有过期读的问题
     • 如果一直有延迟，就一直无法select，但是实际上不需要等待到完全没有延迟，而是只要一个事务完成以后，select到哪个事务即可，不需要等待其他事务也同步完

5. 等主库位点方案

   • select master_pos_wait(file, pos[, timeout]);
     • file pos是主库上的文件名和位置
     • 从库上执行
     • timeout可选，表示超时
     • 返回一个正整数M，表示命令开始执行，到应用完file和pos表示的binlog位置，一共执行了多少个事务
     • 如果备库挂了，那就返回NULL
     • 如果超时，返回-1
     • 如果执行时，已经执行过这个位置了，返回0
   • 具体流程
     • 一个事务执行完，马上在主库上执行show master status得到主库执行到的File和Pos(不需要完全精确)
     • 选一个从库查询
     • 从库上执行select master_pos_wait(File, Pos, 1);
     • 如果返回>=0，则再这个从库上执行查询语句
     • 否则就去主库查询
   • 所以如果不允许过期读的情况出现，那么就超时放弃，或者转到主库查询，并做限流

6. 等 GTID 方案

   • WAIT_FOR_EXECUTED_GTID_SET(gtid_set[, timeout])，超时时间默认为0，如果为0，表示一直等待
     • 语句作用：等待，直到这个库执行的事务包含传入的gtid_set，返回0
     • 超时返回1
   • 5.7版本后，不需要主动执行show master status，而是更新以后返回事务的GTID，减少一次查询
     • session_track_gtids = OWN_GTID
     • 通过API从mysql_session_track_get_first解析GTID即可
   • 具体流程
     • 事务完成，接受到事务的GTID，gtid1
     • 选一个从库查询，执行WAIT_FOR_EXECUTED_GTID_SET(gtid1, 1)
     • 返回0就在这个从库查询
     • 否则去主库查询

1. 主备切换流程
   
   状态1，客户端读写都只访问节点A，B是从库，同步A的更新，保证AB数据相同
   需要切换的时候，就变成状态2，客户端只访问节点B

• 状态1不会操作B，但是建议将B设置为read only
  • 防止他人误操作B
  • 防止切换逻辑出现双写的问题
  • 判断访问节点的角色
  • read only对超级管理员无效，所以可以同步更新的线程有超级权限

2. binlog statement

   • statement就是记录SQL语言，甚至会把注释也都记录进去
   • statement的格式下，delete带有limit，就是unsafe的，会导致主从不一致
   • 删除条件的两个都有索引，如果主从版本不一，可能选择的索引不一致，所以顺序不同，导致delete的东西不同，本质上就是主从库可能delete的时候用到的索引不同，因为有limit存在，比如只删一条数据，就会导致数据不一致。

3. binlog row

   • row里面多了Table_map和Delete_rows
   • Table_map用于说明接下来操作哪个库哪个表
   • Delete_rows用于定义删除行为
   • 实际上，row虽然会占用空间，但是有助于恢复数据，比如误删，可以根据binlog看到，直接插入即可；误增误改都可以这么处理

4. binlog mixed

   • 如果有大量的删，那么row就会记录大量的内容，导致磁盘IO变多，占用空间变多
   • statement就不会，只会有一条语句，但是在某些情况下，会导致不一致
   • 所以mixed判断，如果不会导致不一致就用statement，如果可能会不一致，就切换到row
   • 这个格式用的不多

双M

• 建议设置log_slave_updates=ON，从库执行完relay log以后也生成binlog
• A更新事务，binlog记录A的server id
• B接收到binlog，更新，并记录server id也就是A的server id
• 再传回A，A判断server id等于自身，所以就不会处理日志

并发连接和并发查询

• 线程等待锁的时候，并发线程计数减一
• 因为等待锁的时候不吃cpu资源
• innodb_thread_concurrency设置最大并发线程数

检测MySQL

• 再mysql库中创建一个health_check表，只放一行数据，定期执行
  mysql> select * from mysql.health_check;

• 可以检测因为并发线程过多导致的数据库不可用的问题

  • select 1不行，因为不涉及InnoDB引擎，就算超出限制也会返回
  • 但是这样的话，如果binlog磁盘占满了，也会阻塞commit事务，但是不会阻塞返回，所以这种方法无法判断是否存在磁盘满的情况

• 更新判断：放一个timestamp字段，表示最后一次执行检测的时间：mysql> update mysql.health_check set t_modified=now();

  • 对主从库都需要执行更新检测
  • 为了主备更新不冲突，再mysql.health_check上存入多行数据，用两个库的serverid作为主键
  • 但是可能IO已经100%了，此时正好执行到update语句，那么就无法判断这种情况，不能及时切换
  • 可以通过检测performance_schema里面redolog和binlog的写入时间判断是否存在问题，但是性能损耗10%

误删数据

• delete误删某一行，那么就用binlog恢复即可，需要binlog=row，binlog_row_image=FULL
• 可以将sql_safe_updates=ON预防，如果delete或者update没有写where条件，或者where条件没有索引，就会报错
• 如果需要删全表，则使用truncate table 或者 drop table
• 但是如果drop或者truncate，无法使用binlog恢复，只能全量备份+增量恢复
• 如果对于核心库，可以使用延迟备份，减慢binlog到从库执行的时间，避免被删

kill

• 两个kill命令，kill query + id 和 kill connection + id
• 发送kill命令以后，session运行状态改为THD::KILL_QUERY，并给session发送一个信号
• kill无效
  • 线程没有执行到判断线程状态的逻辑
  • 终止逻辑耗时较长
    1. 大事务被kill，需要回滚
    2. 大事务回滚包含较大的临时文件，压力过大，耗时长
    3. DDL最后阶段
  • ctrl+c命令是服务器开启一个新的线程发送kill query命令

全表扫描

1. 如果扫描一张大表，就获取一行数据，存储到net_buffer中，内存大小由net_buffer_length控制，默认16K
2. 重复获取行，直到net_buffer写满，发送
3. 发送成功清空net_buffer，重复
4. 发送返回EAGAIN或者WSAEWOULDBLOCK，表示本地网络栈写满，进入等待，直到网络栈重新可写，再继续等待

• 所以如果客户端接收的慢，事务执行时间就会变长
  • 可以使用mysql_store_result，将收到的内容存入客户端内存，加快接收速度
  • 但是如果是大查询，就会占用大量内存，就需要使用mysql_use_result

innodb_buffer_pool_size一般设置为可用物理内存的60%-80%，线上服务的内存命中率需要达到99%，可以通过show engine innodb status查看Buffer pool hit rate

• InnoDB淘汰数据页用的LRU的改进
  • 因为如果对一个不常用的表使用全表扫描，这时候就会将别的业务正在使用的内存给顶掉，导致别的业务缓存失效
  • 所以InnoDB按照5:3的比例将LRU分为了young和old区，
    
  • 如图，状态1，访问P3，P3在young区，按照LRU，移到链表头部，变成状态2
  • 此时，要插入新的数据页，淘汰Pm，但是新的数据页Px插入LRU_old处
  • 处于old区的数据页，每次被访问都要做下面的判断：
    • 如果数据页存在超过1s，就移动到链表头
    • 少于1s，位置不变，innodb_old_blocks_time=1000，表示1s
    • 这样扫描大表也用到了buffer pool，但是对于young区没有影响

join

• join应该将小表作为驱动表，大表作为被驱动表，因为InnoDB只会用被驱动表上的索引，对于驱动表，也就是join前面的表，用的是全表扫描。如果驱动表是行数N，被驱动表M被驱动表上索引查询，所以如果回表，就需要在普通索引和主键索引上都查询一次，那么时间复杂度为$2log_2(M)$,驱动表上查询$N$行，所以总共是$N+2log_2(M)$，这就是NLJ
• 这是仅限于可以使用被驱动表的索引，如果被驱动表没有索引，就会使用BNL
  • 将驱动表的数据取出放到join_buffer中，
  • 将被驱动表的每一行跟join_buffer中的数据对比，满足条件放到结果集中
  • 总时间复杂度就是$NM$
  • 这样的话，时间复杂度就是两个表的全表扫描$N + M + NM$
  • 如果驱动表较大，无法放到join_buffer中，就会分段放，join_buffer_size默认256k
    • 就会将驱动表放一部分行，直到join_buffer放满为止，然后将被驱动表取出比对，再清空join_buffer，放驱动表的下一部分数据，直到比对结束
    • 假设N行驱动表分K段，N越大，K越大，所以K表示为$\lambda \times N$，$\lambda \in (0, 1)$
    • 扫描行数就是$N + \lambda \times N \times M$
    • 判断$N*M$次
    • 所以应该让小表当驱动表
• 如果join很慢，就把join_buffer_size改大一些
• 尽量让join走NLJ，并且警惕explain检查字段是否出现Block Nested Loop
• 在决定哪个表做驱动表的时候，应该是两个表按照各自的条件过滤，过滤完成之后，计算参与join的各个字段的总数据量，数据量小的那个表，就是“小表”，应该作为驱动表。
• join比强行拆分单表查询性能更好

Multi-Range Read(MRR)

• 如果一张表有主键id索引，普通索引a，通过a索引扫描，有时候需要回表查询主键
• 此时a虽然是在索引上顺序查询的，但是因为需要回表，所以在主键id索引上就是乱序查的。但是大都数数据都是通过主键自增顺序插入得到的，所以可以认为按照主键递增顺序查询的话对磁盘接近顺序读，性能会更好
• 所以MRR就是先根据索引a找到数据，放到read_rnd_buffer中，(随机读缓冲区)，将缓冲区中的数据按照id递增排序，然后依次在主键中查找。大小由read_rnd_buffer_size控制，如果buffer放满了就会先执行排序，然后查找id返回结果，清空buffer再进行下一步
• 如果想要使用MRR，set optimizer_switch="mrr_cost_based=off"，因为优化器不会判断时使用MRR，所以设置为off，固定使用MRR

Batched Key Access(BKA)

• 当使用join的时候，驱动表一行一行到被驱动表比对，用不上MRR

• 现在将驱动表的内容拿出来，放到join_buffer中，原本join_buffer在BNL里才有暂存驱动表的数据，在NLJ没有用，现在NLJ也会用到

• 然后通过join_buffer跟被驱动表比对

• set optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';通过这条语句开启MRR和BKA，因为BKA基于MRR

• 如果join使用BNL，多次扫描一个冷表，语句执行超过1s，再次扫描冷表就会将数据页放到LRU头部

• 对应的情况就是冷表的数据量小于buffer pool的3/8，能够完全放到old区中。

• 如果冷表很大，业务正常访问的数据页，就没有机会进入young区，这是因为正常访问的数据页要进入young区的话，需要隔1s再被访问到，但是冷表很大，old区在1s内就淘汰了正常数据页，就会导致buffer pool没有这个数据

• 所以大表JOIN不仅会影响IO，IO在join结束也就恢复了，还会影响buffer，需要后面慢慢恢复

BNL对系统的影响

1. 多次扫描被驱动表，影响IO
2. join条件需要执行$M \times N$次对比，大表占用非常多资源
3. 导致buffer pool热数据被淘汰，影响内存利用率

• 可以尝试给被驱动表添加索引

• 如果不适合加索引，比如次数比较少，添加索引不划算。可以建临时表，给临时表加索引，再join即可，优化很好

• 或者自己在业务端实现hash join，会比临时表优化的还好，select * from t1驱动表t1所有数据存入hash结构，比如set之类，select * from t2 where b>=1 and b<=2000获取被驱动表的2000条数据，然后一条一条在业务端跟hash表内容比对即可。临时表需要比较$1k \times 2k$次，但是hash join只需要比较2k次

• 临时表可以用各种引擎，但是内存表只用memory引擎，一般由mysql自动创建销毁

• 临时表建表语法时create temporary table ...

• 一个临时表只能被创建它的session访问，其他session不可见

• 临时表可以与普通表重名

• 如果有同名的，那么show create和增删改查访问临时表

• show tables不显示临时表

• 所以临时表不需要担心重名问题，可以用来给join使用，而且不需要担心数据删除问题

• 分库分表跨库查询就会使用临时表

• 创建临时表的时候，InnoDB创建一个frm文件保存表结构定义，前缀是#sql{进程 id}_{线程 id}_ 序列号
  5.6版本之前，会在临时文件目录下创建一个相同前缀.ibd存放数据文件，5.7版本后有专门的临时表空间存放临时数据，因为前缀不同，所以可以创建同名临时表

• 但是普通表是库名+表名得到的，同一个库创建两个同名表就会报错

• 当session结束的时候，就会执行drop temporary table + 表名

• 如果binlog不是row，就会记录临时表的操作，不然会报错，提示临时表不存在。但是row格式只会记录数据，所以不会有对临时表的操作，不会发现临时表不存在这种问题，就不会记录临时表

内存临时表

1. union的explain会显示using temporary，表示使用临时表，将union前的结果存在临时表中，然后利用主键唯一性剔除第二个查询中的相同的结果

• 如果是union all，就没有去重了，所以也不需要临时表了

2. group by

• 创建内存临时表，表上两个字段m和c，主键是m

• 扫描t1上的索引a，取id，并%10记x

  • 临时表没有x的行，那么插入x,1
  • 如果有x的行，那么对应的c+1
  • group by处理完以后默认会对字段m按照自然顺序排序，如果不想排序提高效率，就可以直接加上order by null
tmp_table_size是内存临时表的大小设置参数，默认16M，超过大小会转为磁盘临时表

• 不管是内存临时表还是磁盘临时表，group by都需要构建一个带唯一索引的表，执行代价高

• 5.7版本支持generated column机制，用来实现数据关联更新alter table t1 add column z int generated always as(id % 100), add index(z);

• 这样索引z上的数据就是group by有序的数据了group by id %100就可以改写为select z, count(*) as c from t1 group by z;此时不再需要临时表，也不需要排序，直接返回即可

• group by语句使用SQL_BIG_RESULT提示，可以告诉sql数据量很大，直接使用磁盘临时表，然后优化器还会将原本的B+树直接改为数组存储 ，两次优化
  select SQL_BIG_RESULT id%100 as m, count(*) as c from t1 group by m;

• 初始化sort_buffer，放入整型字段m

• 扫描t1.a，取id%100放入sort_buffer

• 对sort_buffer中字段m排序

• 排完序就是有序数组

• 这样就不会使用临时表

InnoDB把数据放在主键索引上，其他索引保存主键id就是索引组织表IOT

• 总是有序

• 有空洞时，插入新数据只能放在固定位置，从而保证有序

• 数据位置改变，只需要修改主键索引

• 主键索引查一次，普通索引查两次

• 变长数据
  Memory数据单独存放，索引上保存数据位置，就是堆组织表HOT

• 按照写入顺序

• 有空洞时找到空位就可以插入新数据

• 数据位置改变，需要修改所有索引

• 所有索引地位相同

• 不支持变长，定义varchar，也是 按照char(N)

• 内存表锁表，并且丢失会有风险，一般不会用

  • 但是内存临时表不一样，因为不会被其他session访问，所以没有并发性问题
  • 本来重启就是要删除的，所以丢失没关系
  • 备库临时表也不会影响主库
  • 支持hash索引

• MyISAM主键自增值在数据文件中

• InnoDB主键自增值在内存中，8.0版本实现持久化

  • 5.7版本前没有持久化，保存在内存，重启后就找表的最大值，最大值+1作为自增值
  • 如果id=10，则AUTO_INCREMENT=11，删除id=10，还是11，如果删除以后重启，AUTO=10
  • 8.0版本变更记录在redo log中，重启依靠redo log恢复之前的值

• 插入一行数据，指定为自增，判断id=0，null，或者没有指定，就把表的自增值赋值给他

• 如果id指定了值，就使用指定值；如果指定值小于自增值，则自增值不变；

  • 如果指定值大于等于自增值，就修改自增值，就是auto_increment_offset开始，auto_increment_increment为步长叠加，找到第一个大于指定值作为新的自增值。两个参数默认都是1

• 如果插入数据，自增主键，但是插入数据失败，数据重复了，那么数据无法插入成功，并且主键自增值也没有改回去（唯一键冲突会导致主键自增不连续）

• 事务回滚也会导致自增主键不连续，为了性能，因为申请id很快，但是回滚id可能会导致主键冲突，没有必要

• 批量insert ... select， replace ...select, load data的场景下设置innodb_autoinc_lock_mode=2可以提升并发性，并且不会出现数据一致性问题

• GOROOT: Go语言安装路径
• GOPATH: 若干工作区目录的路径。是我们自己定义的工作空间
  • GO1.8版本之后，开发包安装完成后会自动设置一个GOPATH目录，
  • GO1.14版本之后，推荐使用Go Module模式，不一定非要将代码写在GOPATH目录下，也不需要自己配置GOPATH
• GOBIN: GO程序生成的可执行文件的路径
• GOPROXY: 默认为GOPROXY=https://proxy.golang.org,direct，修改为GOPROXY=https://goproxy.cn,direct

跨平台编译

Windows 编译 LINUX或者OSX

1
2
3
4

SET CGO_ENABLED=0   // 禁用CGO
SET GOOS=linux      // 目标平台, [windows, linux, darwin]
SET GOARCH=amd64    // 目标处理器架构
go build

LINUX 或者 OSX 编译其他环境

1

CGO_ENABLED=0 GOOS=linux|darwin|windows GOARCH=amd64 go build

编写测试

举例

• 有一个main函数，打印Hello world

1
2
3
4
5
6
7
8
9
10
11
12

// hello.go
package main

import "fmt"

func Hello() string {
return "Hello world"
}

func main()  {
fmt.Println(Hello())
}

• 则对应的测试代码应该为

1
2
3
4
5
6
7
8
9
10
11
12

// hello_test.go
package main

import "testing"

func TestHello(t *testing.T){
got := Hello()
want := "Hello world"
if got != want{
t.Errorf("got '%q' want '%q'", got, want)
}
}

• 在终端直接执行go test命令即可进行测试，如果文件名错误，会报错:? gogo [no test files]

重构 t.Helper()

现在有这两个文件hello.go, hellotest.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// hello.go
package main

import "fmt"

const helloPrefix = "Hello "


func Hello(name string) string {
return helloPrefix + name
}

func main()  {
fmt.Println(Hello("world"))
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package main

import "testing"

func TestHello(t *testing.T){
assertCorrectMessage := func(t *testing.T, got, want string){
t.Helper()
if got != want{
t.Errorf("got '%q' want '%q'", got, want)
}
}
    // 成功
t.Run("saying hello to people", func(t *testing.T){
got := Hello("chris")
want := "Hello chris"
assertCorrectMessage(t, got, want)
})
    // 失败
t.Run("say hello world when an empty string is supplied", func(t *testing.T){
got := Hello("")
want := "Hello world"
assertCorrectMessage(t, got, want)
})
}

• 将断言单独作为一个函数，由两个子测试进行调用。
• 第一个子测试能通过，第二个子测试失败
• t.Helper()告诉测试套件这个函数是一个辅助函数，这样测试失败时报告的行号将在函数调用中，而不是在辅助函数内部。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 不添加t.Helper()的输出
--- FAIL: TestHello (0.00s)
    --- FAIL: TestHello/say_hello_world_when_an_empty_string_is_supplied (0.00s)
        hello_test.go:15: got '"Hello "' want '"Hello world"' # 断言函数处的行号，但是具体不知道是哪个测试用例出错
FAIL
exit status 1
FAIL    gogo    0.001s

# 添加t.Helper()的输出
--- FAIL: TestHello (0.00s)
    --- FAIL: TestHello/say_hello_world_when_an_empty_string_is_supplied (0.00s)
        hello_test.go:28: got '"Hello "' want '"Hello world"' # 具体测试用例内部的行号
FAIL
exit status 1
FAIL    gogo    0.001s

命名返回值

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

func Hello(name string, language string) string {
    if name == ""{
        name = "world"
    }
    return greetingPrefix(language) + name
}

func greetingPrefix(language string) (prefix string){
    switch language {
        case french:
            prefix = frenchHelloPrefix
        case spanish:
            prefix = spanishHelloPrefix
        default:
            prefix = englishHelloPrefix
    }
    return 
}

• 在函数签名中，使用了命名返回值prefix string
  • 会自动创建一个名为prefix的变量，并且分配零值，即如果是int，则prefix=0，如果是string，则prefix=""
  • 会在Go Doc中显示，代码更加清晰
  • 只需要直接写return即可，不需要return prefix
• 函数如果是小写字母开头，则是私有函数；如果是大写字母开头，则是公共函数

示例

1
2
3
4
5
6

// integer.go

// Add takes two integers and returns the sum of them
func Add(a, b int) int {
    return a + b
}

• 添加示例函数，示例函数同样会更新在Go Doc中，可以反映出代码的实际功能

1
2
3
4
5
6

// integer_test.go
func ExampleAdd(){
    sum := Add(1, 2)
    fmt.Println(sum)
    // Output: 3
}

1
2
3
4
5
6

=== RUN   TestAdd
--- PASS: TestAdd (0.00s)
=== RUN   ExampleAdd
--- PASS: ExampleAdd (0.00s)
PASS
ok      integer 0.001s

基准测试

1
2
3
4
5
6
7
8

// iter.go
func Repeat(a string) string{
    var repeat string
    for i := 0; i < 5; i++{
        repeat += a
    }
    return repeat
}

• 编写基准测试

1
2
3
4
5
6

// iter_test.go
func BenchmarkRepeat(b *testing.B){
    for i := 0; i < b.N; i++{
        Repeat("a")
    }
}

数组 VS 切片

• numbers := [5]int{1,2,3,4,5}
• numbers := [...]int{1,2,3,4,5}
• 遍历数组的两个方式

1
2
3
4
5
6
7
8

for i := 0; i < 5; i ++{
    ...
}

for _, number := range numbers{
    ...
}
// range返回索引和值，使用空白标志符来忽略索引

接口

• 接口让函数接受不同类型的参数并创造类型安全并且高解耦的代码
• Go语言中 interface resolution 是隐式的。如果传入的类型匹配接口需要的，则编译正确。
• 函数实现因此不需要关心参数是什么类型的，只需要声明一个接口，辅助函数就可以从具体类型解耦而只关心本身需要做的工作

表格驱动测试

• 如果需要测试一个接口的不同实现，或者传入的数据有很多不同的测试需求，则可以使用表格驱动测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

func TestArea(t *testing.T){
areaTests := []struct{
name string
shape Shape
want float64
}{
{name: "Rec", shape: Rec{Width: 12, Height: 6}, want: 72.0},
{name: "Circle", shape: Circle{10}, want: 314.15926},
{name: "Tri", shape: Tri{12, 6}, want: 361.0}, 
}
for _, tt := range areaTests{
got := tt.shape.Area()
want := tt.want
if got != want{
t.Errorf("%#v got '%.2f', want '%.2f'", tt.shape, got, want)
}
}
}

map

• Map是引用类型的，拥有对底层数据结构的引用
• 因此，Map可以是nil指，如果使用一个nil的map，那么会得到一个nil指针异常，导致程序终止
• 永远不要初始化一个空的map变量，比如:var m map[string]string
• 可以用如下两种方式初始化空的map:

1
2

dict = map[string]string{}
dict = make(map[string]string)

• 上述两种方法绝对不会出现nil指针异常

依赖注入

• fmt.Fprintf接受一个Writer参数，将字符串传递过去。
• fmt.Printf是标准的默认输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// di.go
package main

import (
"fmt"
"io"
"os"
)

func Greet(writer io.Writer, name string) {
// fmt.Printf("Hello, %s", name)
fmt.Fprintf(writer, "Hello, %s", name)
}

func main(){
Greet(os.Stdout, "Elodie")
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// di_test.go
package main

import (
"bytes"
"testing"
)

func TestGreet(t *testing.T) {
buffer := bytes.Buffer{} // 注入依赖
Greet(&buffer, "Chris")
got := buffer.String()
want := "Hello, Chris"
if got != want {
t.Errorf("got %s want %s", got, want)
}
}

• Go中不会阻塞的操作在成为goroutine的单独进程中运行。使用go关键字声明

• go test -race可以发现goroutine中的竞争条件，比如可能多个进程同时写一个map，但是一次执行并不会触发这种现象。

• 可以通过channels协调goroutine解决数据竞争问题。

• 比如原本需要将多个进程的数据写入map中，现在可以使用channel <- data，将数据发送到channel中，然后再使用for循环，将数据保存保存在新的map中，这样不会产生数据竞争的问题。result := <- channel

• 在函数调用之前加上defer前缀会在包含他的函数结束时调用它。

  • 有时候需要清理资源，比如在函数结束时关闭一个文件，或者关闭一个服务器，但是要把它放在创建服务器语句附近，以便函数内后面的代码仍然可以使用这个服务器，就可以使用defer，等到函数执行完再调用

进程同步

• select可以轻易实现进程同步

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

func Racer (a, b string) (winner string, err error){
select {
case <- ping(a):
return a, nil
case <- ping(b):
return b, nil
case M- time.After(10 *time.Second):
return "", fmt.Errorf("timed out waiting for %s and %s", a, b)
}
}

func ping(url string) chan bool{
ch := make (chan bool)
go func(){
http.Get(url)
ch <- true
}()
return ch
}

• 如果是v := <- ch等待值发送给channel，则这是一个阻塞调用，因为需要等待值返回
• select允许多个channel等待，第一个发送值的channel胜出。
• 使用select时，time.After是一个很好用的函数，因为channel可能永远不会返回一个值，那就有可能不会返回，因此使用time.After设置超时时间

1
2
3
4
5
6
7
8
9
10
11
12
13

t.Run("returns an error if a server doesn't respond within 10s", func(t *testing.T) {
    serverA := makeDelayedServer(11 * time.Second)
    serverB := makeDelayedServer(12 * time.Second)

    defer serverA.Close()
    defer serverB.Close()

    _, err := Racer(serverA.URL, serverB.URL)

    if err == nil {
        t.Error("expected an error but didn't get one")
    }
})

反射

编写函数 walk(x interface{}, fn func(string))，参数为结构体x，并对 x 中的所有字符串字段调用 fn 函数

• 反射提供了程序检查自身结构体的能力。
• 允许使用类型interface{}，代表任意类型。但是这样市区了对类型安全的检查，编译器不会再检查类型
• 除非真的需要，否则不要使用反射
• 如果想要实现多态，可以考虑围绕接口实现。

单一架构

一个项目，一个工程，导出一个war包，在一个Tomcat上运行

• 应用框架：Spring，SpringMVC，Mybatis
• SpringMVC 在表述层简化跟前端的交互
• Spring 每一层都有
• Mybatis对JDBC的封装，在持久化层简化操作
  

分布式架构

一个项目，多个模块，每个模块是一个module，每个工程都运行在自己的Tomcat上，模块之间可以相互调用，每个模块可以看作是一个单一架构

• SpringBoot是对SSM的封装和简化，节省创建过程
• SpringCloud维护服务之间的互相调用
  

SpringFramework主要功能模块

IoC核心容器

Spring帮助完成组件管理IoC，包括组件对象实例化，组件属性赋值，组件对象引用，组件对象存活周期管理…

• 组件一定是对象，对象未必是组件，组件是映射到应用程序中所有可重用组件的Java对象

IoC容器具体接口和实现类

• BeanFactory接口提供了高级配置机制，可以管理任何类型对象，是Spring IoC容器的标准化超接口
• ApplicationContext是BeanFactory的子接口，扩展了以下功能
  • 更容易与Spring AOP功能集成
  • 消息资源处理(国际化)
  • 特定于应用程序给予接口实现，比如Web应用程序的WebApplicationContext
• BeanFactory提供了配置框架和基本功能，ApplicationContext添加更多特定功能，后者是前者的完整超集

• Spring框架提供了多种配置方式
  • XML配置方式，最早期就有，配置和解析比较复杂，逐渐不使用
  • 注解方式，2.5版本开始存在，在Bean上使用注解替代XML配置信息，将Bean注册到Spring IoC容器中
  • Java配置类方式，3.0版本开始，使用Java编写配置信息，通过@Configuration, @Bean等注解实现Bean和依赖关系的配置

IoC/DI实现步骤

1. 配置元数据

• 基于XML的配置元数据基本结构
• id属性标识单个Bean定义的字符串，随便取，只需要不重复即可
• class属性定义Bean类型并使用全限定类名
• 如果一个组件类，声明两个组件信息，默认是单例模式，会实例化两个组件对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?xml version="1.0" encoding="UTF-8"?>
<!-- 此处要添加一些约束，配置文件的标签并不是随意命名 -->
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
    https://www.springframework.org/schema/beans/spring-beans.xsd">

  <bean id="..." [1] class="..." [2]>  
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>
  <!-- more bean definitions go here -->
</beans>

2. 实例化IoC容器

• 提供给ApplicationContext构造函数的位置路径是资源字符串地址，允许容器从各种外部资源加载配置元数据

1
2
3

//实例化ioc容器,读取外部配置文件,最终会在容器内进行IoC和DI动作
ApplicationContext context = 
           new ClassPathXmlApplicationContext("services.xml", "daos.xml");

3. 获取Bean(组件)

• ApplicationContext是一个高级工厂接口，能够维护不同的Bean以及其依赖项的注册表
• 使用T getBean(String name, Class<T> requiredType)可以检索Bean实例

1
2
3
4
5
6

//创建IoC容器对象，指定配置文件，IoC也开始实例组件对象
ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");
//获取IoC容器的组件对象
PetStoreService service = context.getBean("petStore", PetStoreService.class);
//使用组件对象
List<String> userList = service.getUsernameList();

Bean依赖注入配置DI

1. 配置IoC
2. 配置DI

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

   <!-- 无参构造函数声明IoC --> <bean id="A" class /> <!-- 单构造参数注入 --> <bean id="B" class> <!-- value表示值，此处用不上 --> <!-- ref 表示对另一个IoC对象的引用 --> <constructor-arg ref="A"> </bean> <!-- 多构造参数注入 --> <bean id="B1" class> <!-- 按照顺序赋值 --> <constructor-arg value=""> <constructor-arg value=""> <constructor-arg ref="A"> </bean> <bean id="B2" class> <!-- 按照参数名 --> <constructor-arg name="" value=""> <constructor-arg name="" value=""> <constructor-arg name="" ref="A"> </bean> <bean id="B2" class> <!-- 按照参数下标 --> <constructor-arg index="1" value=""> <constructor-arg index="0" value=""> <constructor-arg index="2" ref="A"> </bean> <!-- setter方法注入 --> <bean id class> <!-- name 是setter方法去掉set和，并且首字母小写的值 --> <!-- value ref 同样二选一 --> <property name ref value> </bean>

读取`IoC组件信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 方式1 创建时指定xml文件即可，可以指定多个，或者一个，也可以无参
ApplicationContext aC = new ClassPathXmlApplicationContext("location1","location2",...);
// 方式2 一般是源码的配置过程
ClassPathXmlApplicationContext aC1 = new ClassPathXmlApplicationContext();
aC1.setConfigLocations("locations");
aC1.refresh();//调用IoC和DI的流程

// 方式1 直接根据bean id获取，返回类型是Object 需要强制类型转换，不推荐
Object h = aC1.getBean("id");
// 方式2 根据bean id获取，同时指定类型
H h1 = aC1.getBean("id", H.class);
// 方式3 根据类型获取，但是同一个类型在IoC容器中只能存在一个，否则报错NoUniqueBeanDefinitionException
// IoC的配置一定是实现类，不能是接口，但是可以根据接口获取值，因为使用了instance of 获取容器类型，接口和实现类的instance of 是相同的
H h2 = aC1.getBean(H.class);

h2.doWork();

Bean组件的作用域和周期方法配置

• 组件类中定义方法，当IoC容器实例化和小会组件对象的时候调用
• 组件声明<bean>只是将Bean信息配置给IoC容器，在容器中，bean标签对应的信息转成Spring内部的BeanDefinition对象
• 包含定义的信息id,class,属性，创建多少个Bean实例对象，由Bean的Scope属性指定

自定义打包文件

1
2
3
4

<build>
    <!-- 自定义打包文件, 需要指定后缀 -->
    <fileName>xxx.war</fileName>
</build>

包含特定的文件

如果一些配置文件没有放在resources/下

有时候Mybatis中会将编写SQL语句的映射文件和Mapper接口都写在src/main/java的某个包中

此时映射文件不会被打包, 就需要单独设置

1
2
3
4
5
6
7
8
9
10
11
12

<build>
    <resources>
        <resource>
            <!-- 设置资源所在目录 -->
            <directory>src/main/java</directory>
            <includes>
                <!-- 设置包含的类型资源 -->
                <include>**/*.xml</include>
            </includes>
        </resource>
    </resources>
</build>

设置自定义插件

可以设置自定义插件, 比如修改jdk版本, tomcat插件, mybatis分页插件, mybatis逆向工程插件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<build>
    <plugins>
        <!-- java编译插件, 配置jdk编译版本 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
        <!-- tomcat插件 -->
        <plugin>
            <groupId>org.apache.tomcat.maven</groupId>
            <artifactId>tomcat7-maven-plugin</artifactId>
            <version>2.2</version>
            <configuration>
                <port>8090</port>
                <path>/</path>
                <!-- 解决tomcat7使用GET请求获取请求参数的时候会乱码的问题 -->
                <uriEncoding>UTF-8</uriEncoding>
                <server>tomcat7</server>
            </configuration>
        </plugin>
    </plugins>
</builid>

Maven依赖的传递特性

• 如果Maven项目B依赖A, C依赖B, 则项目C也依赖于项目A, 执行项目C的时候会下载AB项目的jar包
• 简化依赖的导入过程, 确保依赖的版本正确
• 只有是compile范围的依赖才能够传递, 其他都不能传递, 或者如果设置了<optional>true</optinoal>同样可以终止传递

依赖冲突

• 比如A依赖B, B依赖了X-1.0.jar, A又依赖了C, C依赖了X-2.0.jar, 此时Maven会自动解决冲突

1. 短路优先原则(第一原则)

1
2
3

A --> B --> C --> D --> E --> X (version 1.0)
A --> F --> X (version 2.0)
此时A依赖2.0版本的X

2. 路径长度相同, 则先声明的优先

1
2
3

A --> E --> X (version 1.0)
A --> F --> X (version 2.0)
在<dependencies>中, 先声明的路径相同会先选择

3. 手动排除

1
2
3
4
5
6
7
8
9
10
11
12

<dependencies>
    <dependency>
        <!-- 依赖排除 -->
        <exclusions>
            <exclusion>
                <!-- 需要排除的依赖 -->
                <groupId></groupId>
                <artifactId></artifactId>
            </exclusion>
        <exclusions>
    </dependency>
</dependencies>

继承和聚合

继承关系

• Maven项目中, 一个项目从另一个项目继承配置信息, 共享配置信息, 简化管理和维护
• 可以在父工程中同意管理项目中依赖, 对一个大型的项目进行模块拆分, 一个project下面, 创造很多module, 每个module都有自己的配置信息
• 每个module自己配置自己的依赖信息, 难以统一管理
• 在同一个框架中不同的jar包, 应该是同一个版本, 所以整个项目中使用的框架版本需要统一
• 使用框架需要的jar包组合, 需要反复调试, 最后确定一个可用的组合, 不用在新的项目中重新摸索
• 所以在父工程中为整个项目维护依赖信息组合保证了项目规范, 也可以沉淀技术

1
2
3
4
5
6
7
8
9
10
11
12
13

<!-- 父工程不需要参与打包, 也不需要任何代码, 所以可以直接把src/删掉 -->
<packaging>pom</packaging>
<!-- 然后选中父工程, 右键新建工程, 可以创建子工程 -->
<!-- 子工程groupId和父工程的保持一致 -->
<!-- 子工程会设置父工程坐标 -->
<pareent>
    <artifactId></artifactId>
    <groupId></groupId>
    <version></version>
</parent>
<!-- 子工程只需要artifactId, 因为其他都与父工程保持一致 -->
<!-- 父工程依赖无条件继承到子工程,  但是一般不是所有的依赖每个子工程都需要, 所以会使用DependenceManagement -->
<!-- 然后子工程中选择需要的依赖, 只需要groupId和artifactId即可, version什么都不需要 -->

聚合

• 多个项目组织到一个父项目中, 一起构建和管理, 更好管理一组相关的子项目, 简化部署过程
• 一个命令构建和发布一组相关项目
• 优化构建顺序, 避免依赖混乱构建失败的情况
• 统一管理依赖项, 避免重复定义

1
2
3
4
5
6
7
8
9
10

<project>
    <groupId>com.example</groupId>
    <artifactId>parent-project<artifactId>
    <packaging>pom</packaging>
    <version>1.0.0</version>
    <modules>
        <module>child-project1(路径, 不是工程名)</module>
        <module>child-project2</module>
    </modules>
</project>

私服

• 局域网内的仓库服务, 代理位于外部的远程仓库, 局域网内某个用户需要某个依赖的时候
  • 请求本地仓库, 如果没有
  • 请求私服, 将所需依赖下载到本地仓库, 如果私服不存在
  • 请求外部远程仓库, 下载到私服, 如果外部远程仓库没有, 则直接报错

1
2

# 第一次运行nexus时间较长
./nexus /run 

• 端口号默认为8081
• 如果访问网站卡住就直接命令行ctrl + c
• Type是proxy, 则这个仓库是远程仓库的代理, 帮助从中央仓库中下载依赖, 配置Remote storage即可
• Type是group, 这个仓库是从远程仓库下载到本地存放的仓库(public)
• Type是hosted, 有两个仓库, 分别是正式版本releases和测试版本的snapshots
• 需要修改本地的settings.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<!-- 设置新的本地仓库地址 -->
<localRepository>D:\\new-MvnRepo</localRepository>
<!-- 设置新的远程mirror -->
<mirror>
    <id>nexus-mine</id>
    <mirrorOf>central</mirrorOf>
    <name>Nexus mine</name>
    <url>http://ip:port/repository/maven-public/</url>
<mirror>
<!-- 如果禁止了匿名访问, 还需要继续设置 -->
<server>
    <id>nexus-mine</id>
    <username>admin</username>
    <password>*****</password>
</server>

• 修改IDEA的配置

将jar部署到Nexus

1
2
3
4
5
6
7
8

<distributionManagement>
    <snapshotRepository>
        <id>nexus-mine</id>
        <name>Nexus Snapshot</name>
        <url>....../repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>
<!-- 此处id需要和settings.xml中mirror保持一致 -->

• 然后执行mvn deploy

引用别人部署的jar

1
2
3
4
5
6
7
8
9
10
11
12
13

<repositories>
    <repository>
        <id>nexus-mine</id>
        <name>nexus-mine</name>
        <url>.../repositoryu/maven-snapshots/</url>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <releases>
            <enabled>true</enabled>
        </releases>
    </repository>
</repositories>

与IK分词器一样, 拼音分词器作为插件安装在ES中即可

• pinyin
• 解压, 移动到plugin/, 重启elasticsearch

自定义分词器

• 创建索引库的时候, 使用settings配置自定义的analyzer分词器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

PUT /test
{
    "settings": {
        "analysis": {
            "analyzer": { // 自定义分词器
                "my_analyzer": { // 分词器名称
                    "tokenizer": "ik_max_word",
                    "filter": "py"
                }
            }
        },
        "filter": { // 自定义tokenizer filter
            "py": { // 过滤器名
                "type": "pinyin", // 过滤器类型
                "keep_full_pinyin": false, // 每个中文单独拼音
                "keep_joined_full_pinyin": true, // 使用多个中文的全拼
                "keep_original": true, // 是否保留中文
                "limit_first_letter_length": 16,
                "remove_duplicated_term": true,
                "none_chinese_pinyin_tokenize": false
            }
        }
    }
}

拼音分词器只适合在创建倒排索引的时候使用, 不能在搜索的时候使用, 不然当用户输入中文的时候, 会根据其拼音搜索到其他同音词

通过指定search_analyzer, 可以指定搜索使用不同的分词器

completion suggester查询

这个查询匹配以用户输入内容开头的词条并返回, 为了提高补全查询的效率, 对于文档字段类型有一些约束

参与补全查询的字段必须是completion类型

字段的内容一般是用来补全的多个词条形成的数组

1
2
3
4
5
6
7
8
9
10
11
12
13

GET /test/_search
{
    "suggest": {
        "title_suggest": { // 这边随便起
            "text": "s", // 关键字
            "completion": {
                "field": "title", // 补全查询的字段
                "skip_duplicaties": true, // 跳过重复的
                "size": 10 // 获取前十条结果
            }
        }
    }
}

数据同步

方案1: 同步调用

• 实现简单, 依次执行, 业务耦合, 影响性能

方案2: 异步通知

• 依赖MQ, 解除耦合

方案3: 监听binlog

• 开启binlog增加数据库负担, 实现起来复杂一些

集群

搭建

单机会有海量数据, 单点故障问题

海量数据存储: 将索引库逻辑上拆分成N片(shard), 存储到多个节点(node)中

单点故障问题: 分片数据存储在不同的节点备份(replica)

所以一个分片的主分片和副本分片不会在同一个节点上

编写docker-compose

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

version: '2.2'
services:
  es01:
    image: elasticsearch:7.12.1
    container_name: es01
    environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es02,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - elastic
  es02:
    image: elasticsearch:7.12.1
    container_name: es02
    environment:
      - node.name=es02
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data02:/usr/share/elasticsearch/data
    ports:
      - 9201:9200
    networks:
      - elastic
  es03:
    image: elasticsearch:7.12.1
    container_name: es03
    environment:
      - node.name=es03
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es02
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data03:/usr/share/elasticsearch/data
    ports:
      - 9202:9200
    networks:
      - elastic
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

需要修改权限

1
2
3
4
5

vi /etc/sysctl.conf
# 添加下面内容
vm.max_map_count=262144
# 执行命令使其生效
sysctl -p

监控集群状态

• kibana可以监控, 但是一般只能监控一个节点, 如果要监控整个集群, 需要安装es-x-pack插件, 比较复杂
• 所以使用cerebro监控集群状态, cerebro
• 解压运行即可

指定分片信息

• 可以在创建索引库的时候指定分片信息

1
2
3
4
5
6
7
8
9
10
11
12

PUT /idxName
{
    "settings": {
        "number_of_shards": 3, // 分片数量
        "number_of_replicas": 1 // 副本数量
    },
    "mappings": {
        "properties": {
            // mapping 映射定义
        }
    }
}

节点角色

脑裂问题

• 默认情况下, 每个节点都是master eligible节点, 一旦master节点宕机, 其他候选节点会选举成为一个主节点, 主节点与其他节点网络故障时, 可能发生脑裂问题
• 为了避免脑裂问题(一个集群中出现两个主节点), 要求选票超过(eligible节点数量 + 1) / 2才能当选主节点
  • 因此eligible节点个数最好为奇数, 对应配置项是discovery.zen.minimum_master_nodes
  • es 7.0以后, 已经成为默认配置, 所以一般不会发生脑裂问题

数据分片规则

• coordinating node根据hash算法计算文档应该在哪个分片中
• $shard = hash(\_routing) \ MOD \ number\_of\_shards$
  • _routing默认是文档ID
  • 算法与分片数量有关, 索引库一旦创建, 分片数量不能修改

故障转移

master节点监控集群中的节点状态, 假设一个节点宕机, 会立即将宕机节点的分片数据转移到其他节点, 确保数据安全

如果是主节点宕机了, Eligible Master节点会重新选举出主节点

• pom.xml是Maven的核心配置文件, pom指Project Object Model, 项目对象模型, 将当前项目抽象为文档对象, 再操作整个项目
• Dependency, 依赖管理模型, 主要负责Maven的依赖管理功能
  • 在pom.xml中配置了一个坐标, Dependency就会在本地仓库(local)中找到对应的jar包
  • 如果local没有, 就会通过其他方式(b2b, central中央仓库)下载
• Maven本地仓库中一共存在三种jar包, 自己工程安装到本地仓库的jar包, 从网上下载的第三方jar包, 支持Maven工作的过程中需要用到的jar包

Maven结构

Maven安装需要有JAVA_HOME环境变量

• bin: 包含有Maven的运行脚本, 比如mvn.cmd
• boot: 包含有plexus-classworlds类加载器框架
• conf: 包含核心配置文件, 主要是settings.xml
• lib: 包含运行时需要的Java类库

Maven配置

1. 修改本地仓库位置

   1	<localRepository>D:\MvnRepo</localRepository>

2. maven下载镜像

   1 2 3 4 5 6

   <mirror> <id>alimaven</id> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/groups/public/</url> <mirrorOf>central</mirrorOf> </mirror>

3. maven选用编译项目的jdk版本

   1 2 3 4 5 6 7 8 9 10 11 12

   <profile> <id>jdk-17</id> <activation> <activeByDefault>true</activeByDefault> <jdk>17</jdk> </activation> <properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> <maven.compiler.compilerVersion>17</maven.compiler.compilerVersion> </properties> </profile>

4. IDEA配置本地Maven
   
   
   

Maven工程的GAVP

GroupId, ArtifactId, Version, Packaging, 最后一个是可选项, 如果是Java工程默认就是打jar包

1. GroupId: com.{公司/BU}.业务线.[子业务线], 最多四级, com.taobao.tddl, com.alibaba.sourcing.multilang
2. ArtifactId: 产品线名-模块名, 语义不重复不遗漏, tc-client, uic-api
3. Version: 主版本号.次版本号.修订号, 不兼容api修改应该更新主版本号, 向下兼容功能新增修改次版本号, 修复bug修改修订号
4. Packaging: 指示项目打包为什么类型文件, idea根据packing值, 识别maven项目类型
   • jar表示普通Java工程
   • war表示web工程
   • pom表示不会打包, 用来做继承的父工程, 只负责依赖管理和聚合, 所以不用参与打包

pom.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<modelVersion>4.0.0</modelVersion>
<!-- 这里是指POM版本为4.0.0 -->

<groupId>edu.njupt.maven</groupId>
<artifactId>maven_java</artifactId>
<version>1.0</version>
<!-- 这个是Maven工程坐标 -->

<properties>
<!-- 中间放Maven工程属性 -->
</properties>

<dependencies>
<!-- 依赖 -->
</dependencies>

Maven项目结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

├── pom.xml/                            # Maven 项目管理文件
└── src/                  
    ├── main/                           # 项目主要代码
    |   ├── java/                       # Java源代码目录
    |   |   └── com/example/myapp/   
    |   |       ├── controller/     
    |   |       ├── service/
    |   |       ├── dao/
    |   |       └── model/
    |   ├── resources/
    |   |   ├── log4j.properties        # 日志配置文件
    |   |   ├── spring-mybatis.xml      # Spring Mybatis配置文件
    |   |   └── static/                 # 静态资源目录
    |   |       ├── css/
    |   |       ├── js/
    |   |       └── images/
    |   └── webapp/                     # 存放Web相关配置和资源
    |       ├── WEB-INF/                # 存放Web应用配置文件
    |       |   ├── web.xml             # Web应用的部署描述文件
    |       |   ├── lib/                # 第三方jar包
    |       |   └── classes/            # 存放编译后的classes文件
    |       └── index.html              # Web应用入口页面
    └── test/                           # 项目测试代码, 比如Junit单元测试
        ├── java/                       # 单元测试目录
        └── resources/                  # 测试资源目录

WEB-INF目录下的资源是受保护的资源, 不可通过浏览器直接访问

Maven命令构建

在pom.xml同级目录下运行下面的代码

Maven中测试类的测试方法名需要以testXXX命名, 测试类需要以XXXXTest 或 TestXXXX命名, 否则不会进行测试

如果需要一次性执行多条命令, 可以在mvn后面跟上多条指令, 比如mvn clean test

1
2
3
4
5
6
7
8
9
10
11
12

<!-- war包打包插件和jdk版本不匹配, 打包war会报错 -->
<!-- pom.xml添加如下内容即可 -->
<build>
    <!-- jdk17和war包插件不匹配 -->
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.2.2</version>
        </plugin>
    </plugins>
</build>

生命周期

构建的生命周期可以看作是一组固定构建命令的有序集合, 触发周期后的命令会自动触发周期前的命令

• 构建周期的作用可以简化构建流程
• 一个周期包含若干命令, 包含若干插件

依赖管理

依赖属性

• properties中可以指定属性

  1 2 3 4 5 6 7 8 9 10 11 12

  <properties> <junit.version>5.9.2</junit.version> </properties> <dependencies> <dependency> <groupId></groupId> <artifactId></artifactId> <version>${junit.version}</version> <scope>test</scope> </dependency> </dependencies>

依赖范围(scope)

对应jar包的作用范围为: 编译环境, 测试环境, 运行环境

排序

默认根据相关度分数排序, 可以排序的类型分为keyword, 数值类型, 地理坐标, 日期

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

GET /idxName/_search
{
    "query": {
        "match_all": {},
        "sort": [
            {
                "FIELD": "desc"
            },
            {
                "_geo_distance": {
                    "FIELD": "<lat, lon>",
                    "order": "asc",
                    "unit": "km"
                }
            }
        ]
    }
}

分页

默认只会返回10条数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

GET /idxName/_search
{
    "query": {
        "match_all": {}
    }, 
    "from": 990,
    "size": 10,
    "sort": [
        {
            "price": "asc"
        }
    ]
}
// from 文档开始位置
// size 文档总数

高亮

搜索结果突出显示, 提前用标签标记, 然后对标签添加css样式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

GET /idxName/_search
{
    "query": {
        "match": {
            "FIELD": "TEXT"
        }
    },
    "highlight": {
        "fields": {
            "FIELD": {
                "require_field_match": "false",
                "pre_tags": "<em>",
                "posts_tags": "</em>"
            }
        }
    }
}
// FIELD 表示需要高亮的字段
// pre_tags表示关键字之前的标签
// 不能使用match_all, 因为需要关键字了
// 默认情况下, 搜索字段必须要和高亮字段一致, 也就是两个FIELD需要相同
// 使用require_field_match = false可以解决这个问题

RestClient查询文档

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

void MatchAll() throws IOException {
    // 1. 准备Request
    SearchRequest req = new SearchRequest("xxx");
    // 2. 准备DSL
    req.source().query(QueryBuilders.matchAllQuery());
    // 2.1 排序
    req.source().sort("xxx", SortOrder.ASC);
    // 2.2 分页
    req.source().from(0).size(5);
    // 3. 返回值
    SearchResponse resp = client.search(req, RequestOptions.DEFAULT);
    // 4. 解析结果
    SearchHits hits = resp.getHits();
    // 4.1 获得总数
    long total = hits.getTotalHits().value;
    // 4.2 查询结果数组
    SearchHit[] h = hits.getHits();
    for (SearchHit hh : h) {
        // 4.3 得到source
        String json = hh.getSourceAsString();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

void Highlight() throws IOException {
    SearchRequest req = new SearchRequest("xxx");
    req.source().query(QueryBuilders.matchQuery("all", "xxxx"));
    req.source().highlighter(new HighlightBuilder().field("xxx").requireFieldMatch(false));
    SearchResponse resp = client.search(req, RequestOptions.DEFAULT);
    // ... 处理得到hit
    // 反序列化获取source
    HotelDoc hD = JSON.parseObject(hit.getSourceAsString(), HotelDoc.class);
    // 处理高亮
    Map<String, HighlightField> hF = hit.getHighlightFields();
    if (!CollectionUtils.isEmpty(hF)) {
        // 获取高亮字段结果
        HighlightField hlF = hF.get("xxx");
        if (hlF != null) {
            // 去除高亮结果数组中的第一个, 就是需要的东西
            String name = hlF.getFragments()[0].string();
            // 覆盖非高亮结果
            hD.setName(name);
        }
    }
}

数据聚合

实现对文档数据的统计, 分析, 运算, 不能对Text进行聚合

种类

桶聚合(Bucket)

对文档分组, 默认是对所有文档进行搜索, 限定聚合范围可以使用query条件

1. TermAggregation: 按照文档字段值分组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

GET /idxName/_search
{
    "query": {
        "range": {
            "price": {
                "lte": 200 // 限定聚合范围
            }
        }
    },
    "size": 0, // 设置size = 0, 结果不包含文档, 只包含聚合结果
    "aggs": { // 定义聚合
        "brandAgg": { // 给聚合起名字
            "terms": { // 聚合的类型, 按照品牌值进行聚合, 所以选择term
                "field": "brand", // 参与聚合的字段
                "size": 20 // 希望获取的聚合结果数量
            }
        }
    }
}

2. Date Histogram: 按照日期阶梯分组, 比如一周一组

度量聚合(Metric)

1. Avg: 平均
2. Max: 最大
3. Min: 最小
4. Stats: 同时求min, max, avg, sum等

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

GET /idxName/_search
{
    "query": {
        "range": {
            "price": {
                "lte": 200 // 限定聚合范围
            }
        }
    },
    "size": 0, // 设置size = 0, 结果不包含文档, 只包含聚合结果
    "aggs": { // 定义聚合
        "brandAgg": { // 给聚合起名字
            "terms": { // 聚合的类型, 按照品牌值进行聚合, 所以选择term
                "field": "brand", // 参与聚合的字段
                "size": 20 // 希望获取的聚合结果数量
                "order": {
                    "scoreAgg.avg": "desc"
                }
            }, 
            "aggs": { // 对桶聚合的结果进行统计
                "scoreAgg": {
                    "stats": {
                        "field": "score"
                    }
                }
            }
        }
    }
}

管道聚合(pipeline)

其他聚合的结果为基础进行聚合

1. ES支持的两种地理坐标存储形式

• geo_point: 纬度和经度确定的一个点
• geo_shape: 多个geo_point组成的一个复杂图形, 比如直线, 一般是一个区域

2. 如果ES中同时需要根据名称, 位置, 商圈, 城市等信息进行多个字段的搜索, 又希望性能高一些, 可以使用copy_to

1
2
3
4
5
6
7
8
9

"all": {
    "type": "text",
    "anaylzer": "ik_max_word"
},
"brand": {
    "type": "keyword",
    "copy_to": "all"
}
// 这样就可以在一个字段`all`中查询到所有字段中

JavaRestClient

初始化

1. 引入ES的HighLevelRestClient

1
2
3
4

<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
</dependency>

2. 覆盖SpringBoot默认的7.6.2版本设置

1
2
3
4

<properties>
    <java.version>1.8</java.version>
    <elasticsearch-version>7.12.1</elasticsearch-version>
</properties>

3. 初始化RestHighLevelClient

1
2
3

RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(
    HttpHost.create("http://<ipaddress>:9200")
));

创建索引库

1
2
3
4
5
6
7
8
9

void testCreateIndex() throws IOException {
    // 1. 创建Request对象
    CreateIndexRequest req = new CreateIndexRequest("hotel");
    // 2. 请求参数
    req.source(MAPPING_TEMPLATE, XContentType.JSON);
    // 3. 发起请求
    client.indices().create(req, RequestOptions.DEFAULT);
}
// indices()返回的对象中包含了索引库操作中的所有方法

添加数据到索引库

1
2
3
4
5
6
7
8

void IndexDocument() throws IOException {
    // 1. 创建Request对象
    IndexRequest req = new IndexRequest("idxName").id("1");
    // 2. 准备JSON文档
    req.source(MAPPING_TEMPLATE, XContentType.JSON);
    // 3. 发送请求
    client.index(req, RequestOptions.DEFAULT);
}

查询文档

1
2
3
4
5
6
7
8
9

void GetDocumentById() throws IOException {
    // 1. 创建Request对象
    GetRequest req = new GetRequest("idxName", "1");
    // 2. 发送请求
    GetResponse resp = client.get(req, RequestOptions.DEFAULT);
    // 3. 解析结果
    String json = resp.getSourceAsString();
}

根据ID修改数据

1. 全量更新, 直接删除再重新插入数据
2. 局部更新

1
2
3
4
5
6
7
8
9
10
11

void UpdateDocumentById() throws IOException {
    // 1. 创建Request对象
    UpdateRequest req = new UpdateRequest("idxName", "1");
    // 2. 准备参数, 每两个参数为一对k-v
    req.doc(
        "age", 18,
        "name", "rose"
    );
    // 3. 更新文档
    client.update(req, RequestOptions.DEFAULT);
}

批量导入数据

1. 利用mybatis-plus查询数据
2. 将查询到的数据转换为文档数据
3. 利用JavaRestClient中的Bulk批处理, 实现批量新增文档

1
2
3
4
5
6
7
8
9

void testBulk() throws IOException {
    // 1. 创建Bulk请求
    BulkRequest req = new BulkRequest();
    // 2. 添加需要批量提交的请求, 比如添加两个新增文档的操作
    req.add(new IndexRequest("hotel").id("101").source("json source1", XContentType.JSON));
    req.add(new IndexRequest("hotel").id("102").source("json source2", XContentType.JSON));
    // 3. 发起bulk请求
    client.bulk(req, RequestOptions.DEFAULT);
}

DSL查询语法

分类

1. 查询所有: 有分页, 一次20条, match_all
2. 全文检索: 利用分词器对内容分词后使用倒排索引匹配, match_query, multi_match_query
3. 精确查询: 根据精确词条查询, 一般是keyword, 数值, 日期, boolean, 不分词, ids, range, term
4. 地理查询: 根据经纬度查询, geo_distance, geo_bounding_box
5. 复合查询: 将上述查询组合查询, bool, function_score

语法

1
2
3
4
5
6
7
8

GET /idxName/_search
{
    "query": {
        <查询类型>: {
            <查询条件>: <查询值>
        }
    }
}

全文检索

对用户输入内容分词以后用于搜索框检索

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

GET /idxName/_search
{
    "query": {
        "match": {
            "all": "xxxx"
        }
    }
}

GET /idxName/_search
{
    "query": {
        "multi_match":{
            "query": "xxx",
            "fields": ["1", "2"]
        }
    }
}
// 搜索字段越多, 搜索效率越低, 建议使用`copy_to`将多个字段拷贝到一个字段中