1.thdԴ??
2.慢查询日志中的 Lock_time 从哪里来？
3.MySQL源码阅读4-do_command函数/功能类命令
thdԴ??
价格亲民的音频分离器不易得
对于PS5、Xsx双主机游戏玩家来说，如果对索尼电视、小米S Pro、海信E7K的earc占用了HDMI 2.1端口感到不快，其实这个问题很容易解决，可乐影视源码只需一个两进一出的切换器即可，如果设备较多，可以选择三进或四进，虽然需要手动切换，但这并不是一个大问题。然而，当连接PC显卡时，由于显卡需要读取EDID、DisplayID，这个百元左右的切换器就无法使用了（也许其他支持完整EDID读取的可以）。
另一方面
恰逢当时HDMI2.1直通的功放大批量出现问题，从年开始，这个问题促使我去寻找一款HDMI 2.1音频分离器，后来看到HDfury推出了VRROOM，目前国行代理价格为元，功能很强，但很多是idc网页源码给影院投影用的，还有一款美元的SHARC V2，需要海淘。
因为年在艾森家买过1进4出的分配器，又被某款所谓的HDMI 2.1分离器欺骗过，所以我去找客服陈述了我的需求，没想到客服能谈技术细节，这说明客服很专业。结果就是期待，直到今年年初，有了多块的初代产品，6月份又有了简化版。
4月份测试过一款易拓迅的HDMI 2.1分离器，测试结果是仅PS5勉强可用。当时我已经知道艾森出了一个稍微便宜点的HDMI 2.1 FRL G带宽矩阵+分离器，想着有空再测一测，前几日看活动价已经不到块了，所以买了一个试试，型号HDSWM1。
已满足需求1：4进1出的HDMI 2.1 G带宽切换，支持8KHz和4k Hz的HDR，遥控器操作，等待时间可接受。冰点litv源码能自动切换到最后开机的设备，关闭此设备可以自动切换到另一个有信号的HDMI输入。
已满足需求2：除了PS5、Xsx/ss，显卡HDMI 2.1直通工作正常，实用分辨率为4KHz bit RGB，可以开启Gsync/Freesync/VRR，并从audio only输出全部音轨格式（包括Atmos/THD、Atmos/PCM、LPCM 7.1和DTS:X），分离器设置为pass，HDMI Audio Only需连接AV功放/回音壁的HDMI In（并切换到HDMI输入状态）。
已满足需求3：Xsx/ss的4KHz杜比视界游戏模式可用，全绿。
可满足需求：HDMI CEC公有协议（相对于Bravia sync等私有协议）可用，联动开关机可用。但多设备同时接入，需要考虑清楚联动设置。
未满足需求，电视音频无法通过ARC回传到HDMI Audio Only，只能通过光纤口输出数字音频，莲花口输出模拟音频，lamp源码搭建由于电视机自己有光纤/同轴SPDIF输出，所以意义不大。
临时解决办法是分离器的HDMI 输出连接电视的非ARC 的那个HDMI 2.1口，再用HDMI线连接电视HDMI out/ARC和音响的HDMI in/ARC，但这一思路实操时发现，回音壁或功放的ARC输入优先级高于HDMI输入，一旦arc可用，音响便会切换到ARC输入，导致始终无法切换到HDMI IN状态。
仅在AV功放设置中在某个“场景”中禁用ARC，才可以切换到HDMI IN，回音壁没这个功能，所以这不是个好办法，还不如手动插拔earc的线。
或者再买一个HDMI2.0的earc to HDMI 转换器（仅有1个HDMI In的回音壁，可以再接到4进1出的HDMI IN）。
更：我后来买了一个这个，初步测试可以搭配艾森的4进一出实现earc，只是需要多占用一个HDMI IN，抽空整理测试。
不过呢，因为电视无法输出Atmos/trueHD源码，摇钱树指标源码所以已经买了全景声音响的用户，基本上还是要买播放机才能解决，如果能彻底抛弃电视APP使用外置音响，这就不再是个问题了。
抽空再试试这个4KHz版本。
.7 艾森出了个新的“eARC处理器”，绿色的，但不是矩阵切换方案，支持sonos、bose等仅有HDMI /earc的回音壁，以及HDMI Audio only，这款绿色的两个口都有，通过开关切换。
慢查询日志中的 Lock_time 从哪里来？
在探讨慢查询日志中的 Lock_time 时，首先要了解的是，与这位老相识的关联并不仅限于它表示锁等待时间这一层面，而是深入理解 Lock_time 的构成以及它是如何被计算得出的。
深入研究 Lock_time 之前，我们仅知其代表锁等待时间，却未探入其具体组成与计算过程。在众多 SQL 执行时间较长的场景中，我们时常困惑于 Lock_time 的数值似乎与其等待时间并不成正比，如观察到 Lock_time 仅为 0. 秒。
本文旨在揭开 Lock_time 的面纱，探索它包含的锁等待时间的来源以及计算方式。基于 MySQL 8.0. 源码，我们将重点放在 InnoDB 存储引擎上，通过分析其实现逻辑，以直观呈现 Lock_time 的组成与计算过程。
首先，明确 Lock_time 的计算方法。它由表锁等待时间和行锁等待时间两部分相加形成。这启示我们，对 Lock_time 的理解不仅限于表锁等待时间的考量，还需关注行锁等待时间的计算与累加。
在表锁等待时间的实现中，源码展示了从 Sql_cmd_dml::execute() 函数开始，到 lock_external() 方法的执行，整个过程涉及多个函数和调用，包括 lock_tables()、mysql_lock_tables() 等。这一系列操作最终在 thd->inc_lock_usec() 函数中实现了表锁等待时间的累积。
值得注意的是，表锁等待时间并非单纯反映锁等待过程，它还包含了执行一些初始化操作所需的时间，如同步刷脏页操作。对于 FLUSH TABLES ... WITH READ LOCK 语句，表锁等待时间更包含了将涉及的表所属表空间的脏页同步到磁盘所需的时间。
行锁等待时间的计算则更为直接，主要关注的是在加锁过程中记录的等待时间。通过 sel_set_rec_lock() 函数进行加锁操作，当其他事务持有该记录的行锁时，等待时间即开始计算。通过代码逻辑，我们可直观理解这一过程，即在获取行锁或等待超时后，通过当前时间减去开始时间计算得到行锁等待时间。
综上所述，Lock_time 由表锁与行锁等待时间共同构成，两者在累加的过程中最终形成 Lock_time。表锁等待时间不仅包含锁等待时间本身，还可能涉及额外的初始化操作时间，而行锁等待时间则更为直接且精确。通过深入分析源码，我们对 Lock_time 的构成有了更全面的理解。
MySQL源码阅读4-do_command函数/功能类命令
do_command函数在MySQL的线程循环中执行，分为读取命令和分发执行命令两个主要步骤。
在读取命令阶段，首先设置读取超时（my_net_set_read_timeout），通过vio（Virtual I/O）接口从连接中读取数据。读取时，先解析包头，然后根据包头大小读取数据，同时检查是否超过最大包限制。若数据被压缩，使用zstd_uncompress或zlib_uncompress解压。解析数据并校验，将结果存储到thd对象中。
执行命令阶段，依据获取到的命令执行逻辑，分配内存给String对象。通过dispatch_command函数，进入switch...case...结构，执行不同命令的特定逻辑。功能类命令包括初始化数据库（COM_INIT_DB）、注册从节点（COM_REGISTER_SLAVE）、重置连接（COM_RESET_CONNECTION）、克隆插件（COM_CLONE）、修改用户（COM_CHANGE_USER）等。其他类如数据操作、未实现命令则在后续阅读。
以功能类命令为例，COM_INIT_DB用于改变当前连接的默认数据库。COM_REGISTER_SLAVE则在master节点上注册从节点，启动从节点与master节点的同步。COM_RESET_CONNECTION重置连接，但不创建新连接或更新授权。COM_CLONE命令用于克隆远程插件到本地，并确保一致性。COM_CHANGE_USER允许修改当前连接的用户，并重置连接。
具体操作包括解析请求包、验证、更新thd信息、保存用户连接信息、证书验证、检查密码有效期、限制最大连接数、更新schema属性等。COM_QUIT命令用于清除数据并退出循环。COM_BINLOG_DUMP_GTID和COM_BINLOG_DUMP用于请求发送binlog数据流，而COM_REFRESH命令用于刷新缓存、权限、日志、表、连接主机信息等数据。
在COM_PROCESS_INFO命令中获取进程处理信息，COM_SET_OPTION设置连接属性，COM_DEBUG触发打印调试信息，而COM_PROCESS_KILL用于终止连接。最后，检查是否具有RELOAD_ACL权限并加载数据。
本文总结了do_command函数的命令读取和执行流程，详细介绍了功能类命令的执行情况，为理解MySQL核心工作原理提供了深入洞察。
