代价估计是优化其中非常重要的一个步骤，研究代价估计的原理和MySQL的具体实现对做SQL优化是非常有帮助。本文有案例有代码，由浅入深的介绍了代价估计的原理和MySQL的具体实现。
MySQL内存分配与管理总体上分为上中下三篇介绍，本篇为中篇，主要介绍 InnoDB 的内存构成和使用，代码版本主要基于8.0.25。
MySQL支持了很多Charset与Collation，并且允许用户在连接、Server、库、表、列、字面量多个层次上进行精细化配置，这有时会让用户眼花缭乱。本文对相关概念、语法、系统变量、影响范围都进行了详细介绍，并且列举了有可能让字符串发生字符集转换的情况，以及来自不同字符集的字符串进行比较等操作时遵循的规则。对于最常用的基于Unicode的字符集，本文介绍了Unicode标准与MySQL中各个字符集的关系，尤其详细介绍了当前版本(8.0.34)默认字符集utf8mb4。
在本文中，我们将深入探讨为何选择 iLogtail，以及它在 SPL 数据处理方面相较于 Logstash 有何独特优势。通过对比这两款工具的架构、性能以及功能，我们希望能够揭示 iLogtail 如何在日益复杂的日志处理需求中脱颖而出，帮助您做出明智的技术选择。
如何基于向量数据库+LLM（大语言模型），打造更懂你的企业专属Chatbot。
微服务架构下，有一些需求开发涉及到微服务调用链路上的多个微服务同时改动。通常每个微服务都会有灰度环境或分组来接受灰度流量。我们希望进入上游灰度环境的流量也能进入下游灰度的环境中，确保1个请求始终在灰度环境中传递。即使这个调用链路上有一些微服务应用不存在灰度环境，那么这些微服务应用在请求下游应用的时候依然能够回到下游应用的灰度环境中。我们通过 MSE 提供的全链路灰度能力，可以在不需要修改任何业务代码的情况下，轻松实现上述所说的全链路灰度能力。
ADB PG是一个经典MPP数据库，长项在于查询分析处理，面对客户联机分析和联机交易（HTAP）场景就显得力不从心，我们在某银行核心系统DB2 for LUW迁移到ADB PG时就遇到类似问题，因此我们提出ADB PG+RDS PG混搭技术架构，来解决客户此类HTAP需求。该混搭架构的精髓在于扬长避短，充分发挥分析型数据库和交易型数据库的长处和特性，分析型数据库专注于数据加工跑批场景，然后批量加工的结果数据卸载到RDS PG，通过RDS PG对外提供高并发对客交易服务。
