- 博客(133)
- 资源 (5)
- 收藏
- 关注
RSS订阅原创 快慢指针-Floyd判圈算法
1、1、因为快指针比慢指针速度快，所以如果链表中不存在环时，快慢指针永远不得相遇，直到Fast移动到尾部结束，时间复杂度O（n），因为Fast指针速度是Slow指针两倍，所以当Fast指针到达尾部时，Slow指针走了一般，即可求中间值。即：在第一次相遇时，PC和AC的长度是一样的，因此此时将任意节点重置到A位，并两者均以相同的速度前进，必然会在C点相遇，因此C点为入口点。假如快慢指针此时都在环内，他们相距距离为N，因为环是无效可以循环的，假设次数S指针在F指针前，即S-F=N。
2024-01-15 18:19:47
1019
原创 企业慢SQL案例分析
4、b表使用到了索引material_requirements_detail_k001，索引使用栏位tenantsid，eoc_company_id，eoc_site_id，Server层过滤栏位wo_no、op_no、item_no、item_feature_no、plan_date ，扫描行数2359，成本8669.88，哦豁！在索引最后加上eoc_site_id。在c表执行计划中，使用到了wo_wo_no_IDX索引，且索引栏位为wo_no ，同时存在索引过滤index_condtion。
2023-12-26 17:59:59
910
原创 索引成本计算和优化建议
trace成本分析时可以根据索引成本结果来分析索引选择过程，但是索引成本结果并不是最终执行计划结果，最终的执行计划成本best_access_path，会基于索引成本结果进一步修正，比如每个表的大小、碎片率和使用率不同，所以最终的成本也会不同、另外还有根据当前的系统负载来调整成本。1、索引目的就是快速的定位数据，得出扫描数据，即扫描数据越少索引成本越低，效率越快。2、并不是有了索引就能使用到索引，通过SQL执行流程和成本评估，当扫描行数过大，同时需要回表时，可能最终的成本很高，这时可能会走全表扫描。
2023-12-25 19:46:17
1043
原创 深入了解SQL处理流程原理（Server层与存储引擎交互、数据管理结构）
1、ICP原理：server层在生成执行计划时，会将不能通过索引查询，但是可以利用索引结果进行过滤出的条件下推到存储引擎进行数据过滤，这样可以进一步过滤掉数据，减少后续回表的操作。简单的说，存储引擎本身是一个比较单纯的服务组件，它只负责与硬件交互，进行数据的读取和存储工作，而这一切的读写行为都是按照Server层提供执行计划来实施。2、回表原理：因为索引树中叶子节点数据不能满足需要的栏位，所以需要通过主键ID，到主键索引中查询，这是IO操作，所以要尽量的减少这样的回表操作。
2023-12-23 19:22:31
502
原创 慢SQL减少回表手段
我们知道对于二级索引来说，索引结构中只会存储索引列信息+主键ID，如果需要额外的资讯信息，需要通过主键ID到聚簇索引结构中检索，这样的过程叫做回表，那索引覆盖的本质就是期望可以一次性通过二级索引拿到需要栏位资讯，较少回表操作。然后，存储引擎通过使用索引条目来评估推送的索引条件，并且仅当满足该条件时才从表中读取行。需要注意的是索引覆盖是为了减少回表次数，而二级索引是用于提高检索效率，需要遵循最左原则，如果在已存在的二级索引上进行索引覆盖操作，注意不要影响二级索引的正常使用，建议覆盖栏位滞后。
2023-12-12 16:41:25
862
原创 慢SQL诊断
mysql提供了show profiles和show profile语句提供的分析信息相当的数据，但是需要注意的是在未来的mysql中会弃用当前语句功能，使用性能模式performance_schema来替换，从8.0版本文档中确实没有看到这个语句了，但是听别说依旧可以使用，这个先不管了，反正目前看来mysql5.7在23年10月还在更新维护，那就没什么好说的。mysql 默认是关闭slowlog的，不记录管理语句，也不记录不使用索引进行查找的查询，毕竟这也是一个额外的损耗。具体的使用可以根据需要来定。
2023-12-05 16:58:01
1276
1
原创 Innodb-ruby深入探索Innodb存储结构
这也正对了前面说到的最左原则特性。之前理论知识也说过了，目录页会记录最小索引列编号，来作为目录检索，比如查询34000，那就是在33819~34232区间，指向page 6 号数据页里面，这个时候就会去6号page页检索。这里可以看到在查看了page为3（PRIMARY索引的root页）的页信息后，一共出来95个page信息，对应了上述表述的95个leaf page，同时默认按照主键ID从小到大排序。可以看出来在二级索引的leaf节点中，是没有完整的数据信息的，处理索引列数据，还存储了主键id信息。
2023-12-02 15:56:51
1122
原创 记一篇Centos7安装innodb_ruby
yum安装ruby默认的会安装ruby2.0.0版本，但是在安装innodb_ruby时，会报错，提示至少需要2.4版本以上才能安装。安装innodb_ruby过程非常坎坷，这里记录下安装过程，有些坑当时没有记录下来，主要把完成安装过程就记录下来。这个就比较方面了，直接进入到ruby2.5.0 目录执行卸载程序， make uninstall即可。下了很久很久，后面找了国内镜像地址下载了.....反正哒哒哒一顿安装，结果在下载时候完全卡死。于是赶紧利索的将yum安装的ruby版本卸载了。
2023-11-29 18:22:37
803
原创 Linux安装MySQL 5.7
看到一篇安装Mysql5.7的帖子，比较详细，亲测验证过，这里做个记录转发：Linux安装MySQL 5.7_linux 安装mysql5.7-CSDN博客
2023-11-29 10:50:38
361
原创 大数据量条件SQL查询内存处理方案以及数据过滤算法优化
在索引分析时，需要注意的是，并不是SQL有使用到索引就排除索引问题，执行计划索引分析时，需要关注type栏位，判断出当前是否使用到索引，以及索引使用类型，range、index、all都是需要被重点关注的。评估使用索引栏位查询后的数据量，比如以上案例tenatsid为wo_detail索引栏位，则查看该租户下数据量，如果数据量为2w以内（这里为初略标准，具体可以根据需要输出的栏位以及数据量做内存评估），思想是，在一定数据量前提下，利用索引快速查询冗余数据，同时结合内存快速过滤需要的数据。
2023-11-23 17:39:09
322
原创 实战JVM高CPU、内存问题分析定位
所以程序执行过程中可能产生了大数据量，导致了大对象的诞生，根据Jvm内存分配原理，大对象会直接放入到Old区，并发场景下Old区很快就会被大对象吃满，从而引发FGC。结合当前程序分析后发现，当前API虽然支持分页查询，但是在获取total时，使用原SQL查询所有数据，然后获取size，导致了获取到了7w多笔数据，导致了效能问题。这里可以看到执行了一次API后，Old区上升了约350m，正如上面我们推测的，当前API产生了大对象，直接放入到Old区，并发后导致内存吃满。再PR程序调整后，验证结果。
2023-11-23 17:31:34
199
原创 Kakfa - Producer机制原理与调优
在早期版本的时候元数据是存储在zookeeper中的， 元数据指的是集群中分区信息、节点信息、以及节点、主题、分区的映射关系等。在生产者启动的时候没有元数据的支撑，是无法进行数据的发送的，等于瞎子。metadataUpdater.maybeUpdate方法在第一次被执行时，因为没有元数据节点信息，会执行this.maybeUpdate(now, node)方法，方法内部实现了initiateConnect方法用于客户端建立连接，其底层就是使用的Java Nio的Selector多路复用器。
2023-09-17 16:21:31
486
原创 Redis常见的分区算法方案
在Redis中提出了哈希槽的概念，可以理解为它是将hash环变成 了一个 拥有0~16383个物理槽位（slots）的逻辑环，redis通过redis节点的个数的均匀的分配不同的槽位给redis节点，当有key进来时，通过哈希算法CRC16将key映射到对应的哈希槽位，负责该槽位的redis节点进行管理。因为在Cluster中结点之前是通过PTP ， 流言模式进行交流的，需要一定的网络IO开销，16384是Redis开发者衡量的一个较可靠数量，通知官方也建议实例数不要超过1000。
2023-07-16 17:11:12
620
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人