-没有主键索引 mysql[localhost:8028]{root}(test)>SELECTt.table_schema,t.table_name,t.engine ->FROMinformation_schema.tablest ->JOINinformation_schema.columnsc ->ONt.table_schema=c.table_schema ->ANDt.table_name=c.table_name ->WHEREt.table_schemaNOTIN('mysql','information_schema','sys','p...

Elasticsearch常用命令总结 查看集群健康状态 green：每个索引的primaryshard和replica都是active状态，ES集群正常。 yellow：每个索引的primaryshard是active状态，但是部分的replicashard不是active,ES集群可以正常使用。 red：不是所有索引的primaryshard都是active状态，部分索引数据丢失，集群不可用。 可以通过以下方式查看： http://127.0.0.1:9200/_cluster/health?pretty { "cluster_name":"elasticsearch", "stat...

Elasticsearch性能因素总结 Elasticsearch性能优化可以分为四个模块来进行，分别是硬件、操作系统、Elasticsearch参数配置以及查询优化。 硬件优化 在预算充足的情况下。特别是一些高并发业务的搜索。硬件层面占用整个elasticsearch性能空间很大比例。 内存根据业务量不同，内存的需求也不同，一般生产建议不要少于16G。ES是比较依赖内存的，并且对内存的消耗也很大，内存对ES的重要性甚至是高于CPU的，所以即使是数据量不大的业务，为了保证服务的稳定性，在满足业务需求的前提下，我们仍需考虑留有不少于20%的冗余性能。一般来说，按照百万级、千万级、亿级数据的索引...

1、概述 Pormetheus作为一款免费的第三方监控工具，在通用性及自定义报警项的使用上，都具有非常出色的表现。在大多数的告警配置示例中，阐述了如何添加自定义告警项，如在已有告警的基础上，通过shell脚本增加监控项，完善监控配置。 文章可供参考：Node_Exporter自定义监控指标 但是在实际使用上，经常会发现有一些场景需要在现有告警配置的基础上，做一些减法，排除一些非必要的监控，比如文件系统空间使用率的监控上，经常会有一些系统文件目录会保持一个很高的使用率上，但是不会经常性的改动，如/boot等，当类似的文件系统使用率达到了90%，频繁触发报警，我们该如何处理呢？ 文中将以上图中...

问题概述 现场实施发来求救，简单查询数据表报错， 业务应用出现异常 selectfrommiddXXXXX.t_geo_mv_xxxxxegment_var; ERROR:missingchuunknumber0fortoastvalue142340922inpg_toast_2619 问题原因 此报错信息一般为数据库中有坏块导致。 https://www.postgresql.org/message-id/20211018042128.GB4679@telsasoft.com 解决方案 定位坏块数据，删除坏块数据，从备份还原坏块数据。 查询出哪个表存在坏块： selectre...

适用范围 postgresqlonlinux Linux内核提供了各种可能影响性能的配置选项，为了获得最佳性能，PostgreSQL数据库取决于正确定义的操作系统参数。操作系统内核参数配置不当可能会导致数据库服务器性能下降与系统稳定。因此，必须根据数据库服务器及其工作负载配置这些参数。就像任何其他数据库一样，PostgreSQL依赖于Linux内核进行最佳配置。在这篇文章中，我们将讨论一些可能影响数据库服务器性能的重要Linux内核参数以及如何调整这些参数。因此，在每次优化会话之后对数据库性能进行基准测试以避免性能下降非常重要。 -提示：仅供参考 技术研究 禁用SElinux 在Oracle、...

SQL1耗时200S explain(analyse,buffers,costs,timing) deletefromt_test_delawherea.ctid<>(selectmin(t.ctid)fromt_test_deltwherea.aid=t.aid); 业务表中有大量重复数据，需要对重复数据删除。重复的数据保留一条 Deleteont_test_dela(cost=0.00..79803118.60rows=63362width=6)(actualtime=203492.746..203492.747rows=0loops=1) Buffers:sharedh...

/+set(enable_nestloopoff)set(enable_index_nestloopoff)/ 关闭嵌套查询，走hash /+use_cplan/ 常量和绑定变量执行计划一致 CustomPlan和GenericPlan选择的Hint 语法格式： 指定使用CustomPlan： use_cplan 指定使用GenericPlan： use_gplan 示例： //强制使用CustomPlan,可以看到过滤条件为入参的实际值 openGauss=preparepasselect/+use_cplan/fromtest_bakwhereid=$1; PREPARE ope...

1.3B-tree索引的物理结构 B-tree索引的物理结构，也即索引是如何在数据块中存储的。因此，我们就要了解，根块，分支块和叶子块中的内容都有什么。而为了可以观察到这一结构，我们需要借助和使用Oracle提供的数据块DUMP方法，将指定的数据块内容，输出到跟踪文件中。我们从跟踪文件中观察和了解数据块的内容和结构，进而了解索引的物理结构。 1.3.1观察索引数据块和索引树形结构的基本方法 1、DUMP数据块的方法Oracle提供了DUMP数据块的方法： Altersystemdumpdatafile<n>block<m>; 其中<n>表示目标数据块所在...

索引的访问方法之唯一扫描 2.1跟踪索引的访问方法 如何跟踪索引在使用过程中，是如何实现的索引的唯一扫描，范围扫描、快速全扫描，全扫描和跳跃扫描的呢？这里，我们需要借助Oracle提供的一个专门用于跟踪一致性读（逻辑读）的内部事件—10200event。该事件可以通过在会话级别设置ALTERSESSIONSETEVENTS，来跟踪当前会话中，在哪些数据块上发生了一致性读，以及发生的次序。下面，我们就尝试使用这个内部事件，来分析一下访问索引时，其会按什么样的顺序来访问哪些索引块。 2.2索引唯一扫描 索引唯一扫描（INDEXUNIQUESCAN）一定发生在唯一索引之上，而且，施加在唯一索引列上的...

索引的访问方法之范围扫描 索引范围扫描（INDEXRANGESCAN）可以发生在唯一索引之上，也可以发生在非唯一索引之上。索引范围扫描也是我们最常见到的索引访问方法。索引范围扫描时，并不会像索引唯一扫描那样，一找到满足相关条件的索引条目后即停止，不会再有尝试扫描后续索引条目的动作。而是会一直扫描到第一条不满足相关条件的索引条目后才会停止。这可能是称之为范围扫描的重要原因。而且，当访问的索引不是唯一索引时，即便是在索引列上进行相等的逻辑比较操作，也会访问多个索引条目，并且可能找到多个满足过滤条件的索引条目。 下面，我们沿用索引唯一扫描中构建的表，删除c1列上原有的唯一索引，在c1列上新建一个非唯...

索引的访问方法之快速全扫描 索引快速全扫描（INDEXFASTFULLSCAN）是索引的各种扫描方法中，唯一会以多块读的方式来访问索引。如果把索引想象为表，则其行为类似于全表扫描。 下面，我们继续沿用索引范围扫描中创建的索引，来构建索引快速全扫描的行为并观察之。 图51 我们还是用10200event来跟踪对索引块访问的次序，为节省篇幅，详细的操作步骤这里不再重复，操作方法与索引唯一扫描中的相应操作是类似的。这里，只展示跟踪的结果： 图52 如上图所示，我们可以看到其读取索引块时，是按照数据块在文件中的顺序（块号）来读取的，并不是按照索引块在索引树形结构中的逻辑顺序读取的。 同时，在上...

索引的访问方法之全扫描 索引全扫描（INDEXFULLSCAN）虽然与索引快速全扫描只差了“快速”（FAST），但其访问方法却与后者有明显差别：其一，索引全扫描是单块读，而索引快速全扫描是多块读。其二，索引全扫描是按叶子块的逻辑顺序，依序读取的，所以，它可以保证读取的值是有序的。而索引快速全扫描不能保证。第三，索引全扫描会沿着索引树形结构中定位最左侧（或最右侧）叶子块的路径，访问相关的索引根块和分支块，然后从该最左侧（或最右侧）叶子块开始，沿着叶子块中的双向链表，依序访问全部的叶子块。因此，索引全扫描只会访问部分分支块。 下面，我们仍然沿用前面创建的表和索引，来观察索引全扫描的行为。 由于在我...

索引的访问方法之跳跃扫描 索引跳跃扫描（INDEXSKIPSCAN）是一种只会在组合索引（也称联合索引）上发生的索引访问方法。当我们在A、B两列（也可以更多，但至少要有两列）上创建组合索引后，假设A列在前，B列在后。当我们在SQL的WHERE子句没有用到A列做为过滤条件时，就有可能发生索引的跳跃扫描。之所以称之为“跳跃扫描”，有两种说法：一种是说这种访问方法，好像是“跳“过了前导列A，故名跳跃扫描；另一种说法是当我们从叶子块这一层来观察时，我们会发现前边介绍的四种索引扫描方法（唯一扫描、范围扫描、快速全扫描、全扫描），在叶子块这一层的访问是连续的。比如，唯一扫描只会访问其中一个叶子块；范围扫描...

DML操作时索引的维护 当我们对表进行DML(增、删、改操作)操作时，已存在的索引是如何同步维护的呢？当我们了解并理解了其工作原理后，在对索引进行管理和维护工作时，就可以避免一些对索引认识的错误，从而导致做了一些无用的，甚至是弊大于利的工作。 首先，我们先创建测试用表和索引，如下所示： 图80 如上所示，我们创建了一个名为tab_dml表，该表由两列构成。其中c1列做为测试索引的索引列，其数据类型为char(500)。之所以将其设置为该数据类型，目的是用较少的记录数，就可以模拟出多层的索引。 查看此时索引的树形结构，如下所示： 图81 如上所示，这是一个2层的索引，有1个根块和16个叶...

DML操作时索引的删除行为 当我们将表中原有的一行记录时删除后，相应列上的索引又会怎么做呢？ 执行删除C1列以’985’结尾的记录的操作后，观察叶子块中的数据的变化情况： 图88 如上图所示，我们可以看到表示叶子块中的索引条目数的kdxconro值，仍然为6，即表示此刻该叶子块中，仍然有6条索引条目。而且，表示索引块中可用空间多少的kdxcoavs的值，也没有变化。但是，我们所删除的那一行记录，所对应的“row1[7010]flag:—D—”中，我们可以看到在flag部分出现一个标志“D”，其表示该索引条目已被删除了。 此时，我们如果查看索引的树形结构信息，会看到如下内容： 图89 如...

DML操作时索引的更新行为 我们再来看一下做更新时，索引又是如何做的？ 执行如下SQL，对以’990’结尾的字符串进行更新，更新后的值为以’997’结尾的字符串。 图90 由前边对索引根块的分析（请参见图84）可知，更新后的值，也仍然应落在最后一个叶子块上。查看最后一个叶子块中的数据情况： 图91 如上图所示，从“kdxconro6”来看，索引条目数仍为6，和更新前是一样的。 图92 如上图所示，我们发现更新前的值—以’990’结尾的字符串仍存在，并没有变为’997’结尾的字符串，而是被标记上了删除标志D（row2[6499]flag:—D–）。更新后的新值，是做为一个新的索引条目...

索引的分裂行为 当某个索引块中要插入新的索引条目，但其中又没有可用空间时，就会发生索引的分裂。根据分裂发生所在的索引块类型的不同，可以分为在根块上发生的分裂，在分支块上发生的分裂和在叶子块上发生的分裂。下面，就这三种情况做分别介绍。 从前面的实验中，我们已经看到，大约每个索引块中可以放下13个索引条目。所以，我们通过以下SQL，创建了新的测试表和索引： 图98 查看此时的索引树形结构信息，如下图所示： 图99 如上图所示，目前索引中只有一个索引块，是根块，分支块和叶子块三合一的状态。 查看此时该索引块中的数据内容： 图100 如上图所示，我们可以看到此时索引块中共有13个索引条目（...

问题概述 客户XXX数据库服务器掉电，数据库startup启动数据库遇到ORA-01200错误，信息如下： SQL>startup; ORACLEinstancestarted. TotalSystemGlobalArea997953536bytes FixedSize2259400bytes VariableSize515900984bytes DatabaseBuffers473956352bytes RedoBuffers5836800bytes Databasemounted. ERRORatline1: ORA-01122:databasefile7failedverif...

一、什么是重做日志？   恢复操作最关键的结构是重做日志，它由两个或多个预先分配的文件组成，在数据库发生更改时这些文件存储所有更改。Oracle数据库的每个实例都有一个相关的重做日志，以在实例故障情况下保护数据库。 1.重做线程   在多数据库实例的环境中，每个数据库实例的重做日志也被称为一个重做线程。  在典型的配置中，只有一个数据库实例访问Oracle数据库，因此只有一个线程存在。然而，在OracleRealApplicationClusters环境中，两个或多个实例同时访问一个数据库，并且每个实例都有自己的重做线程。每个实例拥有单独的重做线程可以避免对单个重做日志文件组的争用，从而消除潜...