悟世之路

mysql列存储引擎-查询数据失败-条件核对及外键排查。

stonedb-包含decimal的存在union的派生表-语法不支持-分析相关ISSUE: https://github.com/stoneatom/stonedb/issues/1873

stonedb-包含内连接外连接派生表in子查询和聚合-查询结果错误-处理后反思。

stonedb-包含内连接外连接派生表in子查询和聚合-查询结果错误-原因分析上下文: 2023-06-07 stonedb-包含内连接外连接派生表in子查询和聚合-查询结果错误-分析问题的思路_财阀悟世的博客-CSDN博客

最近在处理stonedb的一个包含内连接包含内连接外连接派生表in子查询和聚合的查询出错的问题, 逻辑非常复杂, 包含的操作符非常多.本文首先从顶层设计出发, 指出如何分析如此复杂的问题。

stonedb-在聚合的场景查询为空无法执行case属性-思考的切入点。

stonedb-在派生表的场景查询为空无法传递默认值-问题分析.本文对该问题的成因, 相关功能的代码设计, 在下一步设计时如何应对这种问题, 做相关的分析。

最近在搞一个列存储引擎的包含内连接的嵌套外连接过慢的问题, 连接执行过慢的原因分析见此前的博客分析, 虽然逻辑很绕, 但是也不是无法分析.更麻烦的问题在于修改查询计划, 让其能按照代价更小的方式争取的执行.遇到的问题比我在修改查询计划前设想的更为棘手, 本文做下记录.

mysql列存储引擎-包含内连接的嵌套外连接查询出错-记录与分析.关联ISSUE: https://github.com/stoneatom/stonedb/issues/1777

最近在处理一个外连接与两表内连接查询过于缓慢的问题, 一个明显的对比是外表进行内连接的耗时极短。本文对该场景和问题的发生做分析。

mysql列存储引擎-parallel_hash_join执行-分析。

外连接相比内连接过于耗时，本文记录其分析过程。

分析join慢查询的执行路径。

mysql列存储引擎-union all与给返回值赋值集合出错-问题分析。

mysql列存储引擎-用户自定义变量比较出错-问题分析关联ISSUE: https://github.com/stoneatom/stonedb/issues/1647

mysql列存储-关于join查询结果出错和查询性能的问题-分析相关ISSUE: bug: When the right table is a derived table of the subquery, the query result will be incorrect either for the left join or for the inner join · Issue #1585 · stoneatom/stonedb · GitHub

对于聚合的处理, mysql列存储引擎性能十分低下,并且会引发内存OOM.在第二阶段的聚合处理为了使用旧有的数据流方式, 做了一些错误的多线程并行分割的设计。现在开启第三阶段的聚合, 以正确的数据流来实现聚合的物化模型。

最近在分析将X100引擎的处理做更为精细化的处理, 一个非常经典的场景以及算子便是聚合的处理。本文对聚合要面临的问题做思考. 其中将视角切换为将mysql列存储的聚合做X100引擎的处理。

最近涉及到对DM工具的一个调研和改造, 并且要作为一个整体的一揽子方案.本文对其做记录。

在mysql的sql层和存储引擎的交互模式中, 存储引擎实现handler接口, 由SQL层负责调用接口, 所以执行的过程可以看作是在sql层中, innodb仅提供接口。但是在mysql列存储引擎中, TMD直接替换掉了sql层的执行接口，并且将sql层的查询树转换成了自己的一套查询树, 然后根据自己的查询树执行查询。本文以以TPCH-Q16为例进行分析查询执行过程。

最近在处理mysql列存储时, 发现在执行explain时, cpu占用达到了100%.本文分析定位该问题的思路过程。

之前在处理的mysql列存储, 与mysql/innodb有显著的差异。作为列存储, 相比于行存, 获取属性不需要提取一整行, 有磁盘IO上的优势。但是这主要表现在全表扫描上面, 本文分析相比mysql/innodb更多的不足。

当前对于mysql列存储引擎, 没有精确的运行时内存使用统计信息.对于后续的性能调优和监控都不利.本文记录内存使用统计的目标, 也就是所谓的需求. 需求决定了功能的边界和架构的设计。

mysql列存储引擎-XOR谓词处理-代码现状分析关联ISSUE: https://github.com/stoneatom/stonedb/issues/769

mysql列存储引擎-用户定义变量-现状记录关联ISSUE: https://github.com/stoneatom/stonedb/issues/958MySQL :: MySQL 5.7 Reference Manual :: 9.4 User-Defined Variables

列存储引擎对于数据的组织有不同的架构, clickhouse是一种模式, 而mysql列存储引擎是一个不同的模式。而mysql列存储引擎的处理方式比较特别，本文做下记录。

聚合部分进行多线程拆分的工作, 耗时了甚久, 其所花费的精力远超设想。其中有路走对的部分, 也有路走错的部分. 但是更多的是很多时候不知道现有的代码是个什么逻辑, 知道代码是在做什么, 但是不知道为什么要这么做， 无法参悟背后的设计思想。到了现在聚合多线程的工作也到一定的阶段，是时候对过去的错误做反思，用来避免在下一步的行动中继续重蹈覆辙了。正所谓前事不忘后事之师。

多线程聚合在扫表时由于LOCK_ONE策略将发生在线程切换时候pack地址丢失.除去已经新增的LOCK_ALL和LOCK_LRU策略, 考虑线程pack标识来作为控制。

记录聚合多线程并行扫表-开发规划。

pack作为mysql列存储引擎中单个列的最小读取单元, 本文分析pack的使用方, 主要在于梳理pack使用方对于列中数据的使用.

使用多线程聚合, 存在额外的代价。在数据量偏少的情况下, 额外的代价将会超过分割数据并行处理减少的代价, 导致总代价出现增高的情况。本文分析多线程聚合的代价, 并确定开启多线程聚合的条件。

聚合的多线程处理,现有代码仅保持读取的最后一个pack.在线程切换后将失效.此前增加了一种lock_all策略, vc_guard不淘汰已读的pack, 持有所有的pack, 等待上层业务释放. 但是lock_all策略没有内存控制机制, 持续的读取pack在超过内存限制后将导致OOM.登录 石原子科技 · 石原子科技所以再新增一种LOCK_LRU策略, 以淘汰掉最近最少使用的pack.本文阐明LOCK_LRU的设计思想.

当前的pack淘汰策略为LOCK_ONE, 在多线程切换时导致pack地址丢失。新设计LOCK_ALL策略以保证多线程聚合正常工作。

多线程并行聚合失败, 本文分析聚合只能串行, 无法并行的原因.注意对聚合多线程失败的的处理, 在分析原因后独立进行, 本文不涉及.工作组模式查询线程开启n个工作线程, 然后查询线程等待工作线程执行完成查询线程合并n个工作线程的聚合结果工作线程分割整个表集合, 局部聚合。

mysql列存储引擎-读取data数据-分析。

mysql列存储引擎-loadData测试。

记录insert-select-的相关需求。

mysql列存储引擎-对比text和varchar性能。

mysql列存储引擎-限制性数字记录。

mysql默认的单个元组长度不能超过65536, 在列存储引擎中, 按列存储。单个元组的长度不再具有意义。本文记录接触单个元组长度限制的需求。