数据库Explain对比
SQL优化整个流程大概可以分为两个步骤:1. 确认性能差的SQL、2.根据执行计划了解导致性能差的原因,尝试针对做优化 Postgres 确定SQL 安装 pg_stat_statement 扩展,安装此扩展后,后续的查询将会被 postgres 记录到 扩展中记录的 pg_stat_statement 中,该记录表会记录 SQL 、查询消耗时间等一系列信息。 使用 慢SQL日志,可在配置文件中对


What else can I do ?
SQL优化整个流程大概可以分为两个步骤:1. 确认性能差的SQL、2.根据执行计划了解导致性能差的原因,尝试针对做优化 Postgres 确定SQL 安装 pg_stat_statement 扩展,安装此扩展后,后续的查询将会被 postgres 记录到 扩展中记录的 pg_stat_statement 中,该记录表会记录 SQL 、查询消耗时间等一系列信息。 使用 慢SQL日志,可在配置文件中对
SQL优化 进行SQL优化之前,我们首先要确定是具体的某条SQL差。一般来说实际开发之中,无非就是两种情况需要对SQL做优化。 开发的时候根据业务需求要做SQL优化 除了实际开发的时候,往往还会有一些SQL会在项目正常运行一定时间之后,才会出现性能差的问题。 针对这种情况。我们可以通过以下几种方式来帮助我们查看过去性能较差的SQL有哪些。 Mysql的性能模式 performance_schema
隔离级别与隔离问题 这个部分算是基础知识,稍微提及一下,具体不再介绍 READ_UNCOMMITED 读未提交 最弱的隔离级别,完全没有隔离效果,等同于可以读取到别人事务之中还没有提交的内容,也就是出现所谓的脏数据的场景。 READ_COMMITED 读已提交 查询只查询到别人已经在事务之中提交了的数据改动,也就是解决了脏数据的可能,但是在这种隔离级别下又出现了事务前后同一个查询语句可能会出现不同
Mysql单表存储不要超过2kw? 有不少文章在解释,Mysql单表最好不要超过2kw,了解时感觉头头是道实际上漏洞百出经不起推敲。有的人甚至会说Mysql指针大小是6,有的又说是12,搞的一塌糊涂根本不知道什么是什么,怪的很。但最终他们的结论是对的,实在有点难绷,为了避免以后又被这群人搞懵导致记错,写一个简单的笔记记录以下正确的推导过程。 他们的实际依据其实就是当B+树的层数增加,会导致Mysq
Mysql 查询某个时间段内数据库执行记录之中,SQL性能、内存消耗、定时器等待时间、索引情况、排序情况等信息的SQL SELECT SCHEMA_NAME AS '模式名', DIGEST_TEXT AS '查询文本', QUERY_SAMPLE_TEXT AS '简易查询文本', SUM_ROWS_AFFECTED AS '总影响的行数', SUM_ROWS_SENT AS '返回行数总和',
前排提醒,该笔记其实已经过时,有一个更新的对MVCC机制和相关Mysql技术介绍更加完整的个人笔记,如有需要请参考Mysql - Innodb 隔离级别的实现 (MVCC、锁机制) - LeticiaFENG Note 如还要参看一下笔记请注意,仅供参考且只涉及MVCC MVCC技术主要涉及以下几个点: 隐藏字段:Innodb实际上对所有行数据都加了三个隐藏的字段,分别是:DB_TRX_ID (用
