提到分区表，一般按照范围（range）来对数据拆分居多，以哈希来对数据拆分的场景相来说有一定局限性，不具备标准化。接下来我用几个示例来讲讲 MySQL 哈希分区表的使用场景以及相关改造点。
在Oracle中，什么是基数（Cardinality）和可选择率（Selectivity）？
日常应用运维工作中，Dev或者db本身都需要统计表的行数，以此作为应用或者维护的一个信息参考。也许很多人会忽略select count(*) from table_name类似的sql对数据库性能的影响，可当你在慢日志平台看到执行了数千次，每次执行4秒左右的查询，你还会无动于衷吗？作为一个有担当敢于挑战的dba，你们应该勇于说no，我觉得类似的需求不可避免但不应该是影响数据库性能的因素，如果连这个都摆不平公司还能指望你干什么。经过几番深思总结，我根据查询的需求，分为模糊查询和精确查询，可以通过下面的三种方式来择优选择。下面测试是线上一个日志表，表大小在6个G左右。
在微信群中，老虎刘老师提了一个有趣的问题，这个SQL，object_id列的可选择性非常高，owner列的可选择性比较差，你认为创建什么索引最佳？
在MySQL数据库中，想了解数据库运行情况的重要指标之一是慢SQL。而并非如某些人所说的所有运行慢的SQL都会被记录在慢SQL日志（或日志表）里，抑或是没有慢SQL就代表没有运行慢的SQL。本文将总结一些比较常见的运行比较慢但不会被记录在慢SQL日志里的情况。另外，慢SQL的计算方式在MySQL8.0新版本中有变化，因此，将通过对比MySQL5.7（MySQL5.7.38）与MySQL8.0（MySQL8.0.33）进行总结。
本文将介绍在11gR2的版本上推出了基数反馈（Cardinality Feedback 以后简称CFB）功能，通过这个特性， 对于某些查询在第一次执行时，如果CBO发现根据统计信息估算出的基数(Computed cardinality)和SQL执行时的实际值差距很大的情况发生时， 在SQL下次执行时，会根据实际值调整基数，重新生成执行计划。
今天介绍两个优化案例，一个是关于min和max这种函数的，另外一个是关于count这个计数函数的。
Oracle10g： create table t_count as select * from dba_objects; create index t_count_i on t_count(object_id): 分别用： select count(*) from t_count; select count(object_id) from t_count; select count(object_name) from t_count; 查看是否使用索引对count查询性能起到作用。 它们的执行计划： SQL> select count(*) from t_count; Execution Plan ---------------------------------------------------------- Plan hash value: 2197880521 ---------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ---------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 39 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| T_COUNT | 12028 | 39 (0)| 00:00:01 | ---------------------------------------------------------------------- Note ----- - dynamic sampling used for this statement SQL> select count(object_name) from t_count;
这是关于MYSQL8 获取信息的方式的第六篇，终于到达了慢日志查询的位置，在MYSQL的DBA 的管理员的心目中，pt-query-digest 和 SLOW QUERY LOG 是分析慢查询的唯一的方式。实际上在MYSQL 8 中这样的慢查询的数据获取方式，已经被淘汰了，或者说不合时宜了。
MySQL 里字段的属性很多，对性能来说，影响也是可大可小，所以针对其属性这一块有必要进行一次探究。
« Oracle基于时间点的恢复 | Blog首页 | 关于Oracle的冲突解决机制的研究 »
某日，群友反馈问题对大表COUNT(*)很慢，但却不会记录到slow log中，这是为什么呢？ 我自己根据他提供的信息，复现了这个问题：
本文为基数反馈（Cardinality Feedback 以后简称CFB）功能的第二部分，主要介绍CFB有效时的状况例子，以及CFB处理流程。
昨天跟同事聊起数据表性能的问题，能不能仅用覆盖索引实现数据的汇总统计。找了一个开发环境已有的数据表进行测试，通过explain命令，能看到mysql通过覆盖索引就能实现sum的需求，而无须去读取实际行数据。
一般在书写SQL时需要注意哪些问题，如何书写可以提高查询的效率呢？可以从以下几个方面去考虑：
先来看一本书（见下图），作者是业界鼎鼎有名的大师级人物Richard Niemiec，从9i、10g到现在的11g，这个优化系列的书，每一本都是厚厚的千页左右，可见大师的称号不是浪得虚名。下面这部最近几年翻译出版的11gR2，书的译者也都是老虎刘非常熟悉和敬佩的几位老朋友，当时也都在甲骨文供职。其中主要的3位译者，杨中是老虎刘在RWP时的老板，朱波和吕学勇在进入甲骨文之前也和老虎刘在同一家公司。这是一本全面介绍Oracle性能相关知识的好书，值得推荐。
近期在客户现场屡次遇到由于统计信息过旧，导致执行计划选错引发的数据库性能问题，今天做个总结。
开发环境，碰见一个谓词越界的问题，模拟这条SQL，如下所示，其中A_ID是表test的外键，并且存在索引，
阅读过上一篇文章的童鞋应该都知道，用count(1)替换count(*)，并不能起到优化作用，两者的执行效率是一样的。那么，count(*)应该如何优化呢？让我们继续往下看。
还有一堆哈 。先用先查就好（现） 比如month addtime。。。。。
统计一个表的数据量是经常遇到的需求，但是不同的表设计及不同的写法，统计性能差别会有较大的差异，下面就简单通过实验进行测试(大家测试的时候注意缓存的情况，否则影响测试结果）。
同大多数关系型数据库一样，日志文件是MySQL数据库的重要组成部分。MySQL有几种不同的日志文件，通常包括错误日志文件，二进制日志，通用日志，慢查询日志，等等。这些日志可以帮助我们定位mysqld内部发生的事件，数据库性能故障，记录数据的变更历史，用户恢复数据库等等。本文主要描述通用查询日志。
今天收到运营同学的一个 SQL，有点复杂，尤其是这个 SQL explain 都很长时间执行不出来，于是我们后台团队帮忙解决这个 SQL 问题，却正好发现了一个隐藏很深的线上问题。
测试版本：Server version: 5.1.58-log MySQL Community Server (GPL)
Oracle索引中最常用的是BTree索引，所以就以BTree索引为例，讲一下BTree索引，BTree索引数据结构是一种二叉树的结构，索引由根块(Root)、茎块(Branch)、叶子块(Leaf)组成，其中叶子块主要存储索引列具体值(Key Column Value)以及能定位到数据块具体位置的Rowid，茎块和根块主要保存对应下级对应索引
Bind Peeking是Oracle 9i中引入的新特性，一直持续到Oracle 10g R2。它的作用就是在SQL语句硬分析的时候，查看一下当前SQL谓词的值 ，以便生成最佳的执行计划。而在oracle 9i之前的版本中，Oracle 只根据统计信息来做出执行计划。
Oracle 10g之后的优化器支持两种模式，一个是normal模式，一个是tuning模式。在大多数情况下，优化器处于normal模式。基于CBO的normal模式只考虑很小部分的执行计划集合用于选择哪个执行计划，因为它需要在尽可能短的时间，通常是几秒或毫秒级来对当前的SQL语句进行解析并生成执行计划。因此并不能保证SQL语句每次都是使用最佳的执行计划。而tuning模式则将高负载的SQL语句直接扔给优化器，优化器来自动对其进行详细的分析，调试并给出建议，这就是Oracle 提供的Automatic Tuning Optimizer，即自动调整优化器。Oracle 自动调整优化器通过SQL调优建议器(SQL tuning advisor)来体现。
多值索引和基于多个字段的联合索引完全不同，联合索引是基于多个一维字段，比如字段 r1 int, r2 int,r3 int，这三个字段的组合是联合索引。一般用于三个字段的联合查找，比如 r1 = 1 and r2 = 2 and r3 = 2 等等。
还有其他命令 explain vectorization operator，explain vectorization expression
数据库是许多网站和应用程序的关键组成部分，是数据在互联网上存储和交换的核心。数据库管理最重要的一个方面是从数据库中检索数据的做法，无论是临时基础还是已编码到应用程序中的过程的一部分。有几种方法可以从数据库中检索信息，但最常用的方法之一是通过命令行提交查询来执行。
大家好我是老羊，由于窗口涉及到的知识内容比较多，所以博主先为大家说明介绍下面内容时的思路，大家跟着思路走。思路如下：
No SQL,No cost. SQL语句是造成数据库开销最大的部分。而不良SQL写法直接导致数据库系统性能下降的情形比比皆是。那么如何才能称得 上高效的SQL语句呢？一是查询优化器为当前的SQL语句生成最佳的执行计划，保证数据读写使用最佳路径；二是设置合理的物理存储结构，如表 的类型，字段的顺序，字段的数据类型等。本文主要描述如何编写高效的SQL语句并给出示例。下面的描述主要分为三个部分，一是编写高效SQL 语句，二是使用索引提高查询性能的部分，三是总结部分。
使用performance_schema中的语句当前事件记录表和语句事件历史记录表可以查询数据库中最近执行的一些SQL语句，以及语句相关的信息，这里我们以events_statements_history表为例，查询结果按照语句完成时间倒序排序，如下：
有5个基础的函数： - filter - select - arrange - mutate - summarise - group_by (plus)
在我的上一篇文章中，我们知道了通过索引或者其他的方式获取数据可能不是语句执行最耗时的操作。比如，MySQL 的GROUP BY可能会占据语句执行时间的90%.
自适应游标共享Adaptive Cursor Sharing或扩展的游标共享(Extended Cursor Sharing)是Oracle 11g的新特性之一，主要用于解决以前版 本中由于绑定变量窥探导致SQL语句无法获得最佳执行计划的缺陷，即能够对效率低下的游标(子游标)进行自动识别而选择最佳的执行计划。本 文详细描述了自适应游标共享并给出示例。 有关绑定变量窥探请参考：Oracle 绑定变量窥探
近日中午一开发过来说生产有条 SQL 执行缓慢，让看一下执行计划。测试环境说也有同样的问题 SQL 且数据量一样，那么则开始在测试环境搞一搞吧，排查过程大概记录如下,对于优化也就是一知半解，故此只能抛砖引玉，如有错误还望指正。
本文示范如何使用OpenMLDB和 Byzer-lang 联合完成一个完整的机器学习应用。Byzer-lang 作为面向大数据和AI的一门语言，通过 Byzer-Notebook 和用户进行交互，用户可以轻松完成数据的抽取，ETL，特征/模型训练，保存，部署到最后预测等整个端到端的机器学习流程。OpenMLDB在本例中接收Byzer发送的指令和数据，完成数据的实时特征计算，并经特征工程处理后的数据集返回Byzer，供其进行后续的机器学习训练和预测。
作者：赵黎明，爱可生 MySQL DBA 团队成员，熟悉 Oracle、MySQL 等数据库，擅长数据库性能问题诊断、事务与锁问题的分析等，负责处理客户 MySQL 及我司自研 DMP 平台日常运维中的问题，对开源数据库相关技术非常感兴趣。
作者：付祥，现居珠海，主要负责 Oracle、MySQL、mongoDB 和 Redis 维护工作。
CREATE 语句用于向当前或指定的 Catalog 中注册库、表、视图或函数。注册后的库、表、视图和函数可以在 SQL 查询中使用。
之前的篇章我们讨论的都是基于单列的分区表，那有无必要建立基于多列的分区表？这种分区表数据分布是否均匀？有无特殊的应用场景？有无特殊的优化策略？本篇基于这些问题来进行重点解读。
生产环境中 select count(*) from table 语句执行很慢，已经远超 long_query_time 参数定义的慢查询时间值，但是却没有记录到慢日志中。在测试环境也很容易复现出该问题，慢查询日志确实没有记录 select count(*) 语句。
针对 datastream api 大家都比较熟悉了，还是那句话，在 datastream 中，你写的代码逻辑是什么样的，它最终的执行方式就是什么样的。
领取专属 10元无门槛券
手把手带您无忧上云
