sql优化

1 MyISAM和InnoDB的区别 　　 a 是否支持行级锁 : 　　MyISAM 只有表级锁 (table-level locking)， 　　而 InnoDB 支持行级锁 (row-level locking)和表级锁,默认为行级锁。 　　 b 是否支持事务和崩溃后的安全恢复： 　　 MyISAM 强调的是性能 ，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。 　　但是 InnoDB 提供事务支持事务 ，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。 　　 c 是否支持外键： 　　MyISAM不支持，而InnoDB支持。 　　 d 是否支持MVCC ： 　　仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。 2 索引 　　MySQL索引使用的数据结构主要有 BTree索引 和 哈希索 引 。 　　对于 哈希索引 来说

什么 mybatis MyBatis是一个支持普通SQL查询，存储过程和高级映射的优秀持久层框架; Mybatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装。Mybatis可以使用简单的XML或注解用于配置和原始映射，将接口和Java的POJO（Plain Old Java Objects，普通的Java对象）映射成数据库中的记录 优点 1、简单易学 mybatis本身就很小且简单。没有任何第三方依赖，最简单安装只要两个jar文件+配置几个sql映射文件易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现 2、灵活 mybatis不会对应用程序或者数据库的现有设计强加任何影响。 sql写在xml里，便于统一管理和优化。通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。 3、解除sql与程序代码的耦合 通过提供DAL层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。 4、提供映射标签，支持对象与数据库的orm字段关系映射 5、提供对象关系映射标签，支持对象关系组建维护 6、提供xml标签，支持编写动态sql。 缺点 1、编写SQL语句时工作量很大，尤其是字段多、关联表多时，更是如此。 2、SQL语句依赖于数据库，导致数据库移植性差，不能更换数据库。

数据库 mysql整体框架 文章目录 数据库 mysql整体框架 1、体系结构 2、存储引擎 2.1MyISAM存储引擎 2.2 InnoDB存储引擎 1、体系结构 连接者：不同语言的代码程序和mysql的交互（SQL交互） 1、 连接池 管理 : 缓冲用户的连接，线程处理等需要缓存的需求 2、 管理服务和工具组件 ：系统管理和控制工具，例如备份恢复、Mysql复制、集群等 3、 sql接口 ：接受用户的SQL命令，并且返回用户需要查询的结果 4、 查询解析器 ： SQL命令传递到解析器的时候会被解析器验证和解析(权限、语法结构) 5、 查询优化器 ： SQL语句在查询之前会使用查询优化器对查询进行优化 6、 缓存 ：如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据 7、 插入式存储引擎 ：存储引擎说白了就是如何管理操作数据（存储数据、如何更新、查询数据等）的一种方法。因为在关系数据库 中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和操作此表的类型） 说明： 在Oracle 和SQL Server等数据库中，所有数据存储管理机制都是一样的。 而MySql数据库提供了多种存储引擎 。 用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎。 甚至一个库中不同的表使用不同的存储引擎，这些都是允许的。 2

在这篇文章中： SparkSQL总体流程介绍 Join基本要素 Join基本实现流程 sort merge join实现 broadcast join实现 hash join实现 inner join left outer join right outer join full outer join left semi join left anti join 总结 文章写的很好，原文路径： https://cloud.tencent.com/developer/article/1005502 Join作为SQL中一个重要语法特性，几乎所有稍微复杂一点的数据分析场景都离不开Join，如今Spark SQL(Dataset/DataFrame)已经成为Spark应用程序开发的主流，作为开发者，我们有必要了解Join在Spark中是如何组织运行的。 SparkSQL总体流程介绍 在阐述Join实现之前，我们首先简单介绍SparkSQL的总体流程，一般地，我们有两种方式使用SparkSQL，一种是直接写sql语句，这个需要有元数据库支持，例如Hive等，另一种是通过Dataset/DataFrame编写Spark应用程序。如下图所示，sql语句被语法解析(SQL AST)成查询计划，或者我们通过Dataset/DataFrame提供的APIs组织成查询计划，查询计划分为两大类

转载 MySQL在 5.0版本中引入新特性：索引合并优化(Index merge optimization)，当查询中单张表可以使用多个索引时，同时扫描多个索引并将扫描结果进行合并。 该特新主要应用于以下三种场景： 1、 对OR语句求并集，如查询SELECT * FROM TB1 WHERE c1="xxx" OR c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果合并（union）操作，得到最终结果 2、 对AND语句求交集，如查询SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果取交集（intersect）操作，得到最终结果 3、 对AND和OR组合语句求结果 该新特性可以在一些场景中大幅度提升查询性能，但受限于MySQL糟糕的统计信息，也导致很多场景查询性能极差甚至导致数据库崩溃。 以SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx" 为例： 1、 当c1列和c2列选择性较高时，按照c1和c2条件进行查询性能较高且返回数据集较小，再对两个数据量较小的数据集求交集的操作成本也较低，最终整个语句查询高效； 2、 当c1列或c2列选择性较差且统计信息不准时

MySQL架构与历史 MySQL逻辑架构 第一层：mysql客户端，负责和mysql服务器连接处理、认证授权、安全、线程处理等。 第二层：大多数mysql的核心功能都在这一层，包括查询解析、分析、优化、查询缓存以及所有的内置函数（如：日期、时间的函数等）,所有夸存储引擎的功能都在这一层实现：存储过程、触发器、视图等。 第三层：包含存储引擎，存储引擎负责mysql中数据的存储、提取、锁机制等。 注：存储引擎不会解析sql。单InnoDB是一个列外，他会解析外键定义，因为mysql服务器本身没有实现该功能。 连接管理与安全性 每个客户端链接都会在服务器进程中拥有一个线程。这个链接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心CPU中运行。 Mysql5.5版本支持线程池插件，可以使用池中少量的线程来服务大量的链接。 当客户端连接Mysql服务器时，会对其进行验证，验证成功后，服务器会继续验证是否具有某个查询的权限。 优化与执行 1.MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。 2.优化器并不关心表用的是什么存储引擎，但存储引擎对于优化查询是有影响的。 3.对于select语句，在解析查询之前，首页会在查询缓存中检查，如果能在查询缓存中检索到结果，那么就不会在进行查询解析、分析

背景介绍 最近在写SQL语句时，对选择IN 还是Exists 犹豫不决，于是把两种方法的SQL都写出来对比一下执行效率，发现IN的查询效率比Exists高了很多，于是想当然的认为IN的效率比Exists好，但本着寻根究底的原则，我想知道这个结论是否适用所有场景，以及为什么会出现这个结果。 网上查了一下相关资料，大体可以归纳为：外部表小，内部表大时，适用Exists；外部表大，内部表小时，适用IN。那我就困惑了，因为我的SQL语句里面，外表只有1W级别的数据，内表有30W级别的数据，按网上的说法应该是Exists的效率会比IN高的，但我的结果刚好相反！！ “没有调查就没有发言权”！于是我开始研究IN 和Exists的实际执行过程，从实践的角度出发，在根本上去寻找原因，于是有了这篇博文分享。 实验数据 我的实验数据包括两张表：t_author表 和 t_poetry表。 对应表的数据量： t_author表，13355条记录； t_poetry表，289917条记录。 对应的表结构如下： CREATE TABLE t_poetry ( id bigint(20) NOT NULL AUTO_INCREMENT, poetry_id bigint(20) NOT NULL COMMENT '诗词id', poetry_name varchar(200) NOT NULL COMMENT

找到mysql的安装目录的bin/myisamchk工具，在命令行中输入： myisamchk -c -r ../data/tablename/posts.MYI 然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql，问题就解决了。 问题分析： 1、 错误产生原因，有网友说是频繁查询和更新dede_archives表造成的索引错误，因为我的页面没有静态生成，而是动态页面，因此比较同意这种说法。 还有说法为是MYSQL数据库因为某种原因而受到了损坏，如：数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致 MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 问题的编号为145 2、问题解决办法。 当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。 这三种修复方法如下所示： % myisamchk --recover --quick /path/to/tblName % myisamchk --recover /path/to/tblName % myisamchk --safe-recover /path/to/tblName 第一种是最快的，用来修复最普通的问题

-------sql数据库优化------ -------索引----- 1.索引的目的：提高查询效率 2.索引分两种 2.1聚集索引（物理），一个表中只能有一个聚集索引 2.2非聚集索引（逻辑），一个表中可以有多个非聚集索引 3.增加索引后，会增加额外的储存空间，同时降低了增加新记录，修改，删除效率 4.只在经常查询的列上建索引，不要建太多索引 ----------语法----------- –增加聚集索引 create clustered index 索引名 on 表名(列名) –删除索引 drop index 表名.索引名 –增加非聚集索引 create nonclustered index 索引名 on 表名(列名) 来源： CSDN 作者： BowenXu11 链接： https://blog.csdn.net/BowenXu11/article/details/104720056

一、前言 在当今的各种系统中，缓存是对系统性能优化的重要手段。MySQL Query Cache(MySQL查询缓存)在MySQL Server中是默认打开的，但是网上各种资料以及有经验的DBA都建议生产环境中把MySQL Query Cache关闭。按道理，MySQL Server默认打开，是鼓励用户使用缓存，但是大拿们却建议关闭此功能，并且国内各个云厂商提供的MySQL云服务中默认都是关闭这个功能，这是为什么？他们在使用中遇到了什么坑？本文将会从以下几方面来详解MySQL Query Cache。 1.MySQL查询缓存是什么？ MySQL缓存规则是什么？ 如何配置和缓存MySQL缓存 MySQL缓存的优缺点 生产要不要开启MySQL缓存 二、 MySQL查询缓存简介 MySQL查询缓存是MySQL中比较独特的一个缓存区域，用来缓存特定Query的整个结果集信息，且共享给所有客户端。为了提高完全相同的Query语句的响应速度，MySQL Server会对查询语句进行Hash计算后，把得到的hash值与Query查询的结果集对应存放在Query Cache中。当MySQL Server打开Query Cache之后，MySQL Server会对接收到的每一个SELECT 语句通过特定的Hash算法计算该Query的Hash值，然后通过该hashi值到Query Cache中去匹配