数据库性能

深秋时节，SequoiaDB 巨杉数据库在深秋给大家带来了“一把火”。SequoiaDB v3.4 正式发布啦！ 分布式交易场景性能大幅提升 SequoiaDB 巨杉数据库3.4版本正式发布，v3.4最重要的特性就是在分布式交易场景下的性能提升。对比上一大版本，SequoiaDB v3.4 在分布式交易场景，读写性能提升达30%，更新性能提升1倍-1.5倍，查询性能较v3.2提升1.5倍以上。 新旧版本性能对比示意 针对分布式交易场景，3.4版本的技术提升主要有以下几个： Improved 2PC Algorithm 分布式事务智能仲裁算法。为分布式事务 2PC 提交增加智能仲裁算法，重点解决 2PC 算法中“In-doubt Transaction” 异常状态，实现数据库在极端场景下为多分区事务智能仲裁，确保分布式事务的强一致性。 Latch-less Memory Model 实现多层级内存池和无锁内存模型。数据库集群池化内存资源，内存池多级管理，会话访问实现 99.99% 内存访问命中率，实现高并发 OLTP 场景下内存的无锁访问，系统CPU的使用率提升 10%。SequoiaDB v3.4同时提供在线内存监控和离线内存分析能力，自动化生成内存分析报告。 Improved Raft Algorithm 突破Raft 算法极限，实现全并发同步。SequoiaDB v3

对于数据库整体的性能问题，AWR的报告是一个非常有用的诊断工具。 一般来说，当检测到性能问题时，我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长，那么AWR报告就不能很好的反映出问题所在。 还应该收集一份没有性能问题的时间段的AWR报告，作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的，比如都是半个小时的，或者都是一个小时的。 关于如何收集AWR报告，请参照如下文档： Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point 注：最好一开始我们从ADDM报告入手，因为对应时间段的ADDM报告往往已经指出了问题所在。 参见: Interpretation 在处理性能问题时，我们最关注的是数据库正在等待什么。 当进程因为某些原因不能进行操作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得最大的好处。 AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息，可以让我们只关注主要的问题。 Top 5 Timed Events 正如前面提到的，"Top 5 Timed Events"是AWR报告中最重要的部分

深秋时节，SequoiaDB 巨杉数据库在深秋给大家带来了“一把火”。 SequoiaDB v3.4 正式发布啦！ 分布式交易场景性能大幅提升 SequoiaDB 巨杉数据库3.4版本正式发布，v3.4最重要的特性就是在分布式交易场景下的性能提升。 对比上一大版本，SequoiaDB v3.4 在分布式交易场景，读写性能提升达30%，更新性能提升1倍-1.5倍，查询性能较v3.2提升1.5倍以上。 新旧版本性能对比示意 针对分布式交易场景，3.4版本的技术提升主要有以下几个： Improved 2PC Algorithm 分布式事务智能仲裁算法。为分布式事务 2PC 提交增加智能仲裁算法，重点解决 2PC 算法中“In-doubt Transaction” 异常状态，实现数据库在极端场景下为多分区事务智能仲裁，确保分布式事务的强一致性。 Latch-less Memory Model 实现多层级内存池和无锁内存模型。数据库集群池化内存资源，内存池多级管理，会话访问实现 99.99% 内存访问命中率，实现高并发 OLTP 场景下内存的无锁访问，系统CPU的使用率提升 10%。SequoiaDB v3.4同时提供在线内存监控和离线内存分析能力，自动化生成内存分析报告。 Improved Raft Algorithm 突破Raft 算法极限，实现全并发同步。SequoiaDB v3

Redis、Memcache和MongoDB的区别 https://www.cnblogs.com/tuyile006/p/6382062.html >>Memcached Memcached的优点： Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle。 Memcached的局限性： 只支持简单的key/value数据结构，不像Redis可以支持丰富的数据类型。 无法进行持久化，数据不能备份，只能用于缓存使用，且重启后数据全部丢失。 无法进行数据同步，不能将MC中的数据迁移到其他MC实例中。 Memcached内存分配采用Slab Allocation机制管理内存，value大小分布差异较大时会造成内存利用率降低，并引发低利用率时依然出现踢出等问题。需要用户注重value设计。 >>Redis Redis的优点： 支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算） 支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。

MySQL_基础知识 -----基础知识 1、什么是数据库？ 数据库(Database)是按照数据结构来组织、存储和管理数据的仓库 2、什么是关系型数据库、主键，外键，索引分别是什么？ 关系型数据库是由多张能互相联接的二维行列表格组成的数据库 主关键字(primary key)是表中的一个或多个字段，它的值用于唯一地标识表中的某一条记录 外键表示了两个关系之间的相关联系。以另一个关系的外键作主关键字的表被称为主表，具有此外键的表被称为主表的从表。外键又称作外关键字 在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单 3、表的链接查询方式有那些，有什么区别？ 交叉连接即笛卡儿乘积，是指两个关系中所有元组的任意组合 使用内连接时，如果两个表的相关字段满足连接条件，就从这两个表中提取数据并组合成新的记录 自连接是一种特殊的内连接，它是指相互连接的表在物理上为同一张表，但可以在逻辑上分为两张表 外连接是只限制一张表中的数据必须满足连接条件，而另一张表中的数据可以不满足连接条件的连接方式 4、SQL的select语句完成的执行顺序？ 1、from 子句组装来自不同数据源的数据； 2、where 子句基于指定的条件对记录行进行筛选； 　 3、group by

1. 从RDBMS到NoSQL的架构演化 互联网时代背景下大机遇，为什么用nosql 1 单机MySQL的美好年代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1.数据量的总大小 一个机器放不下时 2.数据的索引（B+ Tree）一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 如果出现了上述1 or 3个上述瓶颈，架构开始演化到下一个阶段： 2 Memcached(缓存)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展

9.1 使用autotrace功能辅助sql优化 oracle sql*plus提供一个autotrace的功能，可以用于跟踪sql的执行计划，收集统计信息，通常被作为sql的优化工具之一而被广泛使用。 9.1.1 autotrace功能的启用 autotrace有几个常用选项，简单说明如下： set autotrace off：不生产autotrace报告，这是缺省模式； aet autotrace on explain：autotrace只显示优化器执行路径报告； set autotrace on statistics：只显示执行统计信息； set autotrace on：包含执行计划和统计信息； set autotrace traceonly：同set autotrace on，但是不显示查询输出。 9.1.2 autotrace功能的增强 9.1.3 autotrace功能的内部操作 当使用autotrace功能时，在数据库内部，oracle实际上是启动了2个session连接，一个session用于执行查询等操作，另外一个session用于记录执行计划和输出最终结果等操作。 这两个session都是由一个进程衍生。select * from v$process;一个进程在数据库中可能对应多个session。 主要的操作步骤如下： （1）执行计划的输出 （2）统计信息输出

数据库（分库分表）中间件对比 https://www.cnblogs.com/cangqiongbingchen/p/7094822.html 基本概念：分区，分片，分表，分库 分区：对业务透明，分区只不过把存放数据的文件分成了许多小块，例如mysql中的一张表对应三个文件.MYD,MYI,frm。 根据一定的规则把数据文件(MYD)和索引文件（MYI）进行了分割，分区后的表呢，还是一张表。分区可以把表分到不同的硬盘上，但不能分配到不同服务器上。 优点：数据不存在多个副本，不必进行数据复制，性能更高。 缺点：分区策略必须经过充分考虑，避免多个分区之间的数据存在关联关系，每个分区都是单点，如果某个分区宕机，就会影响到系统的使用。 分片：对业务透明，在物理实现上分成多个服务器，不同的分片在不同服务器上 个人感觉跟分库没啥区别，只是叫法不一样而已，值得一提的是关系型数据库和nosql数据库分片的概念以及处理方式是一样的吗？ 请各位看官自行查找相关资料予以解答 分表：当数据量大到一定程度的时候，都会导致处理性能的不足，这个时候就没有办法了，只能进行分表处理。也就是把数据库当中数据根据按照分库原则分到多个数据表当中， 这样，就可以把大表变成多个小表，不同的分表中数据不重复，从而提高处理效率。 分表也有两种方案： 1. 同库分表：所有的分表都在一个数据库中，由于数据库中表名不能重复

一、查询服务器状态和配置 列出MySQL服务器运行各种状态值： mysql> show global status; 查询MySQL服务器配置信息语句： mysql> show variables; 二、慢查询 mysql> show variables like '%slow%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | log_slow_queries | ON | | slow_launch_time | 2 | +------------------+-------+ mysql> show global status like '%slow%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | Slow_launch_threads | 0 | | Slow_queries | 4148 | +---------------------+-------+　 配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长

数据库命令规范 • 所有数据库对象名称必须使用小写字母并用下划线分割 • 所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） • 数据库对象的命名要能做到见名识意，并且最后不要超过 32 个字符 • 临时库表必须以 tmp_为前缀并以日期为后缀，备份表必须以 bak_为前缀并以日期 (时间戳) 为后缀 • 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低） 数据库基本设计规范 1. 所有表必须使用 Innodb 存储引擎 没有特殊要求（即 Innodb 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 Innodb 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 Innodb）。 Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。 2. 数据库和表的字符集统一使用 UTF8 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。 3. 所有表和字段都需要添加注释 使用 comment 从句添加表和列的备注