• 关于慢查询的参数slow_query_log_file，它指定慢查询日志文件的存放路径，系统默认会给一个缺省的文件host_name-f参数里面修改。
• 假如运行时间正好等于long_query_time的情况，并不会被记录下来。也就是说，在mysql源码里是判断大于long_query_time，而非大于等于。

• 查看慢 SQL 的阈值时间，默认阈值时间为 10s

在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具mysqldumpslow。

创建函数，保证每条数据都不同

• 随机产生部门编号的函数

• 创建往emp表中插入数据的存储过程

• 创建往dept表中插入数据的存储过程

• 是mysql提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优测量

• 执行如下指令开启全局查询日志

• 此后，你所执行的sql语句，将会记录到mysql库里的general_log表，可以用下面的命令查看
• • 【必须】从服务器唯一ID
  • 【可选】启用二进制文件

  修改配置文件后的准备工作

  • 因修改过配置文件，主机+从机都重启 mysql 服务

  注意主机和从机的防火墙设置，要么都关闭要么设置开放端口号

  • 创建用户， 并赋予从机 REPLICATION 权限（从主机的数据库表中复制表）

在 Linux 从机上配置需要复制的主机

• 如何停止从服务复制功能

本网6月7日讯  为了帮助数据库开发者、用户和对数据库有兴趣的同学，更好地了解和运用数据库，柏睿数据数据库团队特别策划出品《深入浅出话DB》系列文章，以全内存分布式数据库RapidsDB为实例开启连载，从数据库高性能入手，到柏睿数据经典实战案例解读，带你走进全内存分布式数据库的世界。第四回，并发查询，Here we go！

相信各位朋友都有这样的认知，传统分析型分布式数据库对海量数据处理能力很强，就是任务并发表现上就略显无力。那么作为新型的分析型分布式数据库，RapidsDB又有什么手段处理并发查询？RapidsDB在底层存储、工作负载、分布式服务3个层面并发查询上优化：

首先的也是最核心的存储引擎层面上：RapidsDB的存储引擎使用使用无锁跳表，使得RapidsDB以非常高吞吐量进行高度并发的读写。

那么无锁跳表索引又有什么不同，它是怎么体现优势？

无锁跳表索引：又称跳表索引，它是RapidsDB中的默认索引类，对比其他大多数数据库（比如MYSQL）使用的B-Tree索引。跳表索引被RapidsDB优化为在内存中运行，它不仅可以实现无锁并提供极快的插入性能。而且它提供Btree类似的O(log(n))查找性能，非常适合顺序遍历。

但跳表索引也有与B-trees不同的地方，RapidsDB中的跳表索引是单向的（也就是单链表）。混合跳表索引中的每一列都可以指定为升序（ASC）或降序（DESC），默认值为升序。选择哪一个不会影响查找性能，但会影响数据扫描性能，具体取决于索引的数据扫描的方向。反向扫描跳表索引的成本大约是正向扫描的两倍。因此，如果用户有一个升序索引，并且运行一个按降序遍历该索引的查询（例如按ORDER BY DESC的顺序），那么该查询将需要比索引DESC更高昂的迭代。

比如对于数据增删改等写入操作。传统的关系型数据库管理系统使用磁盘作为数据的主要存储，使用内存作为缓存。管理这个缓存层时会增加开销并引发资源争用，从而降低吞吐量和并发性。这些限制导致随机读写I/O，这会给旋转和固态磁盘带来了巨大的压力。RapidsDB主要将数据存储在内存中，并以压缩格式备份到磁盘。因此，RapidsDB只使用顺序I/O，并且事务日志的大小会小很多。这种I/O模式针对旋转磁盘和固态磁盘进行了优化。此外，RapidsDB中的读取可以使用内存优化的无锁跳表和哈希表，这些都不会被在缓存池中管理。

在内存中运行的跳表在这种样的设计下，可以自由地直接使用指向行的指针，而无需像传统数据库那样，检索行需要通过其他方式而不是指向内存的指针来寻址，因为传统数据库的数据主要存储位置在磁盘上。这种间接访问通常采用内存驻留页面缓存（通常称为缓冲池）的形式，查询该缓存是为了找到特定行的内存地址，或者在需要使用时先将数据从磁盘读入内存。

这种间接检索方式对系统开支很昂贵，并且通常在页面级别完成（例如，在 SQL Server中一次 8K）。而RapidsDB没有这种计算开销。取消引用指针的跳表索引比在缓冲池中查找页面要节省资源得多。

无锁（或者叫非阻塞）算法是RapidsDB索引的另外一个特点：数据库线程始终可以运行，完全适应操作系统对线程的调度执行。这也是RapidsDB支持在多核CPU硬件上运行的高并发工作负载的原因。它还摆脱了Btrees需要使用复杂的锁定方案来实现线程安全的困局。对比较新的无锁索引数据结构，例如BWtree，虽然可以避免这个问题。但同样，BWTree数据结构的复杂性远远超过了跳表甚至传统的Btree本身。因此跳表的简单性使其非常适合无锁实现。

使用无锁数据结构来优化对表的其他数据库中的B-trees有相似的功能和性能特征。跳表是为有序数据优化的数据结构，它将行存储在越来越小的有序列表集合中。查询可以通过使用不同大小的列表进行二进制搜索来快速查找数据，并且可以通过遍历最大的列表来快速扫描数据范围。对于多列索引，查询筛选器必须匹配索引列列表的前缀，以便能利用该索引。

其次是工作负载层面上：遇到需要跨分片数据移动的查询，即涉及表数据进行广播和重新分区的查询，通常比其他查询请求更多的连接和线程。这类查询的并发性由工作负载管理自动管理。在大多数情况下，工作负载管理的默认设置将适当地安排用户的工作负载，以利用集群资源，而不会耗尽连接和线程限制。

最后是分布式服务层面上：分布式查询优化器通过平均分配处理大量工作，以最大限度地提高CPU使用效率。查询计划被编译为机器代码并且被缓存，来加速后续的查询，这些经过编译的查询计划的一个关键特征是它们并没有预先设定的参数值。这个机制允许RapidsDB能根据不同的请求来替换这些值，这使得相同查询结构的后续查询能够快速的执行，大大提高并发执行的效率，尤其是同类查询的效率。

（本内容转载于网络，文中图片等内容如有侵权，请联系编辑删除。市场有风险，选择需谨慎！此文不作选择参考。）

"查询缓存" ---是把将查到的结果缓存下载，如果查询语句相同，则直接把缓存的结果返回.

如果应用程序在某一个场景 多次需要查询，且不需要经常更新，则使用查询缓存可以有一定的性能提升。 
如图所以可以查看是否开启了缓存功能 

?SQL_CACHE：显式指定存储查询结果于缓存之中
缓存条件即会缓存，否则，不予缓存，显式指定SQL_NO_CACHE，不予缓存，
定SQL_CACHE的SELECT语句才会缓存；其它均不予缓存 
# 查询缓存相关的状态变量： 
 

 
 


 Qcache_lowmem_prunes：记录因为内存不足而被移除出查询缓存的查询数
 

 
————————————————
 


?读写相互阻塞，写入不能读，读时不能写
?读取数据较快，占用资源较少
?不支持MVCC（多版本并发控制机制）高并发
 

 ————————————————
 


 

 


 

 只读（或者写较少）、表较小（可以接受长时间进行修复操作）
 

 ————————————————
 


 

 


?支持事务，适合处理大量短期事务
?读写阻塞与事务隔离级别相关
?从MySQL5.5.5开始为默认的数据库引擎 

所有InnoDB表的数据和索引放置于同一个表空间中
表空间文件：datadir定义的目录下
每个表单独使用一个表空间存储表的数据和索引
两类文件放在数据库独立目录中
?查看mysql支持的存储引擎
查看当前默认的存储引擎
查看库中所有表使用的存储引擎
查看库中指定表的存储引擎