网上看到一个帖子说他们公司部署了一个基于AI去操作数据库的功能，然后用了10分钟后发现数据库被删了，大家觉得AI驱动数据库可取吗？

Redis自己本身是通过C语言实现的，但是他并没有直接使用C语言中的字符数组的方式来实现字符串，而是自己实现了一个SDS（Simple Dynamic Strings），即简单动态字符串，这是为什么呢？

1.  数据库分布键调整【分布键选取原则】   分布式表的分布策略有几种，其中主要是有复制分布、HASH分布、范围分布，其中对于Hash分区表，Hash分布表的分布列选取至关重要，需要满足以下原则：1、 列值应比较离散，以便数据能够均匀分布到各个DN。例如，考虑选择表的主键为分布列，如在人员信息表中选择身份证号码为分布列。2、 在满足第一条原则的情况下尽量不要选取存在常量filter的列。例如，表dwcjk相关的部分查询中出现dwcjk的列zqdh存在常量的约束(例如zqdh=’000001’)，那么就应当尽量不用zqdh做分布列。3、 在满足前两条原则的情况，考虑选择查询中的连接条件为分布列，以便Join任务能够下推到DN中执行，且减少DN之间的通信数据量。4、 对于Hash分表策略，如果分布列选择不当，可能导致数据倾斜，查询时出现部分DN的I/O短板，从而影响整体查询性能，不同DN的数据量相差5%以上即可视为倾斜，如果相差10%以上就必须要调整分布列。 业务表在分布式场景下，分布键如果不指定默认用第一列，对这边第一列大部分都是xxxxx字段，而这个字段的值都是9999，从而导致数据都分布在一个节点上。本次根据实际业务情况，调整了800张左右表的分布列，对于小表且改动比较少采用复制表方式，其他表是参照列值的散列情况及索引创建等按hash方式进行分布，调整后系统性能得到初步改善；【数据分布检查语句】select * from pgxc_get_table_skewness where schemaname=’xxxxx’ order by skewratio desc;若skewratio大于0.1，需要重点关注。2.  XLOGS分盘将XLOG日志文件目录单独放在一块nvme盘上，方式通过软链接方式实现，从而减轻数据盘压力，提高数据库整体IO能力。如：ln -s /data/dn_6001/pg_xlog  /data/cluster/data/dn/dn_6001/pg_xlog3.   数据库参数调整针对关键参数进行调整GaussDB参数参数说明推荐值默认值分类名称资源消耗内存max_process_memory设置一个数据库节点可用的最大物理内存(物理内存大小 - vm.min_free_kbytes)* 0.7 / (1 + 主节点个数)Cn:110GBDn:320GB视系统、部署情况而定shared_buffers设置GaussDB Kernel使用的共享内存大小；建议设置shared_buffers值为内存的40%以内，如果设置较大的shared_buffers需要同时增加checkpoint_segments的值，因为写入大量新增、修改数据需要消耗更多的时间周期Cn:4GBDn:160GB视系统、部署情况而定work_mem设置内部排序操作和Hash表在开始写入临时磁盘文件之前使用的内存大小。ORDER BY，DISTINCT和merge joins都要用到排序操作。Hash表在散列连接、散列为基础的聚集、散列为基础的IN子查询处理中都要用到128MB视系统情况而定maintenance_work_mem设置在维护性操作（比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中可使用的最大的内存。该参数的设置会影响VACUUM、VACUUM FULL、CLUSTER、CREATE INDEX的执行效率。建议设置此参数的值大于work_mem，可以改进清理和恢复数据库转储的速度1GB视系统情况而定max_prepared_transactions设置可以同时处于"预备"状态的事务的最大数目。增加此参数的值会使GaussDB Kernel比系统默认设置需要更多的System V共享内存　1200　内核资源消耗max_files_per_process设置每个服务器进程允许同时打开的最大文件数目。如果操作系统内核强制一个合理的数目，则不需要设置。1024 1024 最大连接数Max_connections数据库会话最大连接数18000根据实际情况而定  线程池开启enable_thread_pool控制是否使用线程池功能，一般都开启On on 控制线程池功能的详细属性thread_pool_attr设置线程池功能的详细属性。该参数分为3个部分：1) thread_num：线程池中的线程总数，取值范围是0~4096。其中0的含义是数据库根据系统CPU core的数量来自动配置线程池的线程数，如果参数值大于0，线程池中的线程数等于thread_num。2) group_num：线程池中的线程分组个数，取值范围是0~64。其中0的含义是数据库根据系统NUMA组的个数来自动配置线程池的线程分组个数，如果参数值大于 0，线程池中的线程组个数等于group_num。3) cpubind_info：线程池是否绑核的配置参数。Cn:2048,2,(nobind)Dn:4096,2,(nobind)根据实际情况设置4.  慢SQL调优4.1查询top SQL的语句：select n_calls,unique_sql_id,substr(query,1,50) as query,total_elapse_time/n_calls/1000 as avg_time,total_elapse_time/1000 as runtime from dbe_perf.statement where user_name='cbsprd' and n_calls>10 and avg_time>5 order by runtime desc;4.2慢SQL存在主要几种表现：1） 存在重分布（分布式数据库独有现象），即选择分布列不合理，导致数据在DN之间需要进行重分布，从而影响性能调整分布列前：在***_jyyxrz表存在重分布，这个表的分布为piljybss；而***_jykzhq的分布列为pljyzbsh，两个表关联存在重分布情况。优化方案：将***_jyyxrz的分布列也调整为pljyzbsh，且两表关联也是带这个条件的，其执行情况如下：优化结果：消除dn节点间数据重分布，时间从原来13ms提升至7ms。2） 未走索引，全表扫描从上图可以看出，若出现“seq scan on ……”即表示表未走索引，增加耗时。在***_jyyxrz_0704上增加索引后，如下图：优化结果：走上索引扫描，运行时间从361ms降为6.6ms3） 未使用最佳索引此问题出现在***_sfdjbu的索引上，kcgb_sfdjbu_idx10是创建一个（shoufdma,jiluztai,shouqibz,kehuzhao,sfkhuzhh,guiylius）复合索引，但该语句的where中sfkhuzhh字段上使用了or，故不能采用一个复合索引，由此创建两个索引新建索引字段如下：增加索引后，SQL语句改走这两个，时间从原来的95ms缩减到9.5ms4） SQL改写因分布式场景及gaussdb和oracle的SQL语法差异性，存储少数复杂SQL的改写，具体如下：改写前：改写后的SQL语句：将or exist改写为union all的方式，来减少数据的遍历，从而提升性能，时间从原来的89秒降低到82毫秒。5）加SQL PATCH：总之，单SQL优化是多方面的，是一个持续过程，直到满足性能要求为止。

什么是数据库的锁升级，InnoDB支持锁升级吗?

mysql中如何查看一个sql的执行耗时?

mysql用了索引一定会索引失效吗?

索引的长度太长有影响吗?为什么更推荐前缀索引？

联合索引是越多越好吗?我多建几个索引不是更好吗?

为什么MySQL会选错索引，如何解决？它是怎么进行索引选择的？

大学一直强调数据库范式，外键约束，但是实际工作中经常是反范式，不做外键约束。是正常的吗？为什么工作中不建议使用外键约束。

在进行DDL期间会阻塞DML动作吗?

where条件的顺序影响使用索引吗?比如有一个联合索引<a,b>,where a,b或者where b,a有区别吗

数据库字段加密后如何做模糊查询?

使用存储过程的弊端?

一、 https://bbs.huaweicloud.com/forum/thread-02127175758735800042-1-1.html问：区分度不高的字段适合建立索引吗?比如说状态字段0,1这种答：如状态字段（0,1）通常不适合建立索引，因为它们的索引效果不明显，且会增加存储和维护成本。特殊情况下，如果低区分度字段非常频繁地用于查询条件，或与其他字段组合使用，可以考虑建立索引。二、 https://bbs.huaweicloud.com/forum/thread-0225175758780310047-1-1.html问：mysql的驱动表是什么?小表驱动大表性能一定好吗?left join一定是左表作为驱动表吗?如何来指定驱动表?答：什么是驱动表？驱动表是查询优化器选择的第一个被处理的表，通常用于生成初始的行集合。然后，这些行会被用来在其他表中查找匹配的行。例如，在一个JOIN操作中，驱动表通常是先被完全扫描或使用索引进行访问的表，而其他表则根据驱动表生成的行来查找匹配的记录。小表驱动大表性能一定好吗？不一定。选择驱动表时需要考虑多个因素：1）表的大小：一般来说，选择较小的表作为驱动表可以减少初始行集合的大小，从而减少后续JOIN操作的开销。但这不是绝对的。2）索引的存在和使用：即使小表作为驱动表，如果大表上有合适的索引，查询性能也可以非常高效。反之，如果小表没有合适的索引，即使它较小，也可能导致低效的查询。3）查询条件：查询条件和过滤条件也会影响表的选择。如果某个表上有非常严格的过滤条件，使得最终需要处理的行数非常少，这个表可能更适合作为驱动表。LEFT JOIN一定是左表作为驱动表吗？不一定。虽然在LEFT JOIN中，左表通常是驱动表，但MySQL的查询优化器可能会根据实际情况选择更合适的表作为驱动表。例如，如果右表有更严格的过滤条件或更高效的索引，优化器可能会选择右表作为驱动表。如何来指定驱动表？虽然MySQL的查询优化器通常能选择最优的执行计划，但在某些情况下，可以使用STRAIGHT_JOIN、查询提示或子查询来指定驱动表。三、https://bbs.huaweicloud.com/forum/thread-0225175758834574048-1-1.html问：什么是buffer pool,它的作用是什么?工作中好像没有用到过，它重要吗答：Buffer Pool是数据库管理系统中的一块内存区域，专门用于存储从磁盘读取的数据页。当数据库需要处理数据时（如查询或更新），它首先检查Buffer Pool中是否已经存在所需的数据页。如果存在（称为缓存命中），数据库可以直接从内存中读取数据，避免了相对慢速的磁盘I/O操作；如果不存在（称为缓存未命中），则需要从磁盘加载数据到Buffer Pool中，然后再进行处理。为了最大化性能，Buffer Pool会根据一定的算法（如LRU，最近最少使用算法）自动管理哪些数据页应该保留在内存中，哪些应该被移出，以适应不断变化的查询需求。** Buffer Pool的作用 **提高查询性能：通过缓存频繁访问的数据，减少从磁盘读取数据的次数，极大地提高了查询速度。减少I/O开销：减少了对物理磁盘的访问，降低了系统因等待I/O操作完成而产生的延迟。支持并发操作：多个并发的查询可以同时访问Buffer Pool中缓存的数据，提高了系统的并发处理能力。即使在你的工作中可能没有直接与Buffer Pool打交道，了解其工作原理对于理解数据库性能优化仍然是非常重要的。例如：性能调优：合理配置Buffer Pool的大小对于优化数据库性能至关重要。一般来说，Buffer Pool越大，可以缓存的数据越多，性能越好，但需要权衡服务器的内存资源。故障排除：当遇到数据库性能瓶颈时，分析Buffer Pool的使用情况（如缓存命中率）可以帮助识别和解决问题。四、https://bbs.huaweicloud.com/forum/thread-0218175933309908056-1-1.html问：如何避免InnoDB的页分裂答：InnoDB是MySQL默认的存储引擎，使用B+树索引结构来存储数据。当InnoDB表的数据页（通常是16KB大小）中没有足够的空间来存储新插入或更新的行时，如果选择的是随机插入或更新，数据页可能会发生分裂，变成两个页。页分裂会影响性能，因为需要分配新的页和重写部分数据。以下是几种避免InnoDB的页分裂的方法：预分配表空间：使用ALTER TABLE table_name ENGINE=InnoDB;命令可以重建表，预分配表空间，减少因空间不足而引起的页分裂。在创建表时使用ROW_FORMAT=COMPRESSED或ROW_FORMAT=DYNAMIC，这可以优化存储空间，减少页分裂的频率。合理设计索引：尽量减少每个索引的大小。例如，如果可以，使用更短的字段类型或前缀索引。选择合适的索引字段顺序。通常，将更经常更新的字段放在后面，因为频繁更新可能导致页内频繁的数据重排。考虑数据插入的顺序：如果可能，按照索引的顺序插入数据。例如，如果主键是自增的，那么按照这个顺序插入数据可以避免页分裂。对于非自增主键或二级索引，如果数据可以预先排序，这也能减少页分裂。定期维护：定期执行优化表的操作，如OPTIMIZE TABLE，这可以帮助回收未使用的空间，整理表结构，减少页分裂。定期检查表的状态，使用SHOW TABLE STATUS命令查看Data_free字段，判断是否有大量未使用的空间需要回收。调整InnoDB参数：通过调整innodb_file_format, innodb_file_per_table等参数，可以根据需要进一步优化表的存储效率和性能。监控和分析：使用性能监控工具来跟踪数据库的性能，包括页分裂的频率和相关指标。分析慢查询日志，找出可能引起页分裂的查询，优化这些查询。通过上述措施，可以有效减少InnoDB表的页分裂，从而提高数据库的整体性能。五、https://bbs.huaweicloud.com/forum/thread-0218175933366117057-1-1.html问：mysql的自增主键用完了怎么办答：当MySQL中的自增主键（例如 AUTO_INCREMENT）达到其数据类型的上限时，会引发问题，因为新的插入操作将失败。以下是一些处理这种情况的步骤和方法：检查当前主键值首先，检查当前自增主键的值，确保确实接近其上限。更改主键数据类型如果当前使用的主键数据类型是较小的类型（如 INT），可以考虑将其更改为更大的数据类型（如 BIGINT）。处理数据如果已经接近上限，但不想改变主键数据类型，可以考虑以下几种方法：1 ）重新分配主键值可以删除一些不再需要的记录，或者重新分配主键值。这通常需要备份数据，重置主键值，然后再插入数据。2） 使用复合主键如果单个自增主键已经不足以满足需求，可以考虑使用复合主键。分片（Sharding）如果单个表的自增主键经常接近上限，可以考虑将数据分片到多个表中。每个表可以有自己的自增主键，从而扩展主键的使用范围。使用UUID如果自增主键不再适合你的需求，可以考虑使用UUID作为主键。虽然这会增加存储空间和索引的复杂性，但可以避免主键上限的问题。定期监控定期监控自增主键的使用情况，提前发现并处理问题。可以设置警报，当主键接近其上限时发出通知。调整自增步长和偏移量虽然调整自增步长和偏移量不能解决主键用完的问题，但可以在某些情况下减少冲突和提高性能。使用外部生成的唯一标识符可以使用应用程序生成唯一标识符，而不是依赖数据库的自增主键。例如，使用Snowflake算法生成全局唯一的ID。通过以上方法，可以有效地处理和预防MySQL中自增主键用完的问题。选择哪种方法取决于你的具体需求和数据规模。六、https://bbs.huaweicloud.com/forum/thread-0251176001433250058-1-1.html问：数据库乐观锁的过程中，完全没有加任何锁吗答：乐观锁并不是完全没有加锁，而是加锁的方式和时机与传统的悲观锁不同。乐观锁假设数据在大多数情况下不会发生冲突，因此在读取数据时不会立即加锁，而是在更新数据时才进行检查和加锁。在读取数据时，乐观锁不会加任何锁，允许多个事务同时读取数据，这提高了并发性和性能。在更新数据时，乐观锁会检查数据是否在读取后被其他事务修改过。如果数据没有被修改，则更新数据；如果数据已被修改，则更新失败，通常会抛出异常或回滚事务。乐观锁通常通过版本号或时间戳来实现。每个记录都有一个版本号或时间戳字段。在读取数据时，会记录下当前的版本号或时间戳。在更新数据时，会检查当前版本号或时间戳是否与读取时的版本号或时间戳一致。如果一致，表示数据未被修改，可以更新；如果不一致，表示数据已被修改，更新失败。总的来说，乐观锁在大多数情况下通过减少锁的竞争提高了并发性和性能，但在某些高并发写入的场景下可能需要谨慎使用。七、https://bbs.huaweicloud.com/forum/thread-0225176001459744064-1-1.html问： mysql中的order by+limit为什么会数据重复?答：在MySQL中，ORDER BY 和 LIMIT 一起使用时，通常不会导致数据重复。如果出现数据重复的情况，可能是由以下几个原因引起的：没有唯一性约束：如果你的查询结果中没有一个唯一约束（例如，主键或唯一索引），在排序和限制结果时，可能会出现重复的行。这是因为如果没有唯一性约束，MySQL可能无法确定行的顺序，从而导致在不同的查询执行中返回相同的行。并行查询和锁定：在高并发环境下，多个查询同时执行时，如果没有适当的锁定机制，可能会导致数据重复。例如，如果一个查询在读取数据时，另一个查询正在插入或更新数据，可能会导致结果集中出现重复的行。分页查询：在分页查询中，如果使用 LIMIT 和 OFFSET，且结果集中有相同的排序值，可能会导致重复的行出现在不同的页面中。例如，假设你有一个包含 name 列的表，并且 name 列中有多个相同的值，使用 ORDER BY name LIMIT 10 和 ORDER BY name LIMIT 10 OFFSET 10 可能会在不同的页面中返回相同的行。索引选择：MySQL 在处理 ORDER BY 和 LIMIT 时，可能会选择不同的索引。如果选择的索引不包括所有需要的列，可能会导致额外的排序操作，从而影响结果的唯一性。临时表和文件排序：当查询结果集很大时，MySQL 可能会使用临时表或文件排序来处理 ORDER BY。如果临时表没有适当的唯一性约束，可能会导致重复的行。八、https://bbs.huaweicloud.com/forum/thread-0251176001480025059-1-1.html问：什么是事务的二阶段提交答：事务的二阶段提交（Two-Phase Commit, 2PC）是一个用于管理数据库事务的机制，旨在确保在系统故障或网络问题发生时，数据库的状态保持一致。它通过分阶段的提交来防止部分提交（Partial Commit）导致数据不一致的问题。两阶段提交的实现步骤第一阶段：检测 Abort（检测阶段）在第一阶段，系统尝试检测数据库中的所有修改是否可以一致。如果任意一个检查失败，系统将立即回滚所有修改（Aborting the transaction）。第二阶段：提交（决议阶段）仅在检测阶段没有发现任何冲突或不一致的情况下，系统才会将所有修改永久性地提交到数据库中。