sql优化

SQL Server优化器特性-位图过滤(Bitmap)

一曲冷凌霜 提交于 2020-03-30 06:57:02
一直以来,由于SQL Server中没有位图索引使得面对一些场景,从业人员在索引选择上受限,饱受诟病.其实熟悉SQL Server的朋友应该知道,SQL Server虽然没有位图索引,但在特定环境下还是会采用位图(Bitmap)过滤的,这次就为大家介绍下SQL Server的位图过滤. 概念:关于位图索引的概念我就不做过多介绍了,感兴趣的朋友可以看下wikipedia http://en.wikipedia.org/wiki/Bitmap_index 优势:在重复率高,数据很少被更新的场景中(如一年之内的年龄,汽车车型等)过滤高效. SQL Server的位图过滤采用的布隆过滤(bloom filter)方式,这里我简单说下布隆过滤的实现方式. 实现方式:通过构建一个长度X的位数组(bit array)(所有位为0),将要匹配的集合通过哈希函数映射到位数组中的相应点中(相应位为1),当判断一个值是否存在时找bit array中对应位是否为1就可以了.这个过程由SQL Server内部自己完成. 如图1-1所示,我将需要匹配的集合{神仙?,妖怪?,谢谢!}映射到bit array中,当有一条新记录{悟空..}我判断他是否在我的集合中,只需判断相应的位是否是1就可以了,图中可以看出{悟空..}并不是所有位都为1,所以悟空并不在我的集合中. 图1-1 具体到SQL

Select语句执行顺序

泪湿孤枕 提交于 2020-03-30 04:45:02
目的在于理解如何Select 【搜索所得】: 标准的 SQL 的解析顺序为: (1).FROM 子句, 组装来自不同数据源的数据 (2).WHERE 子句, 基于指定的条件对记录进行筛选 (3).GROUP BY 子句, 将数据划分为多个分组 (4).使用聚合函数进行计算 (5).使用 HAVING 子句筛选分组 (6).计算所有的表达式 (7).使用 ORDER BY 对结果集进行排序 上述未有Select语句。 为了准确说明Select语句所在位置: 1. FROM clause 2. WHERE clause 3. GROUP BY clause 4. HAVING clause 5. SELECT clause 6. ORDER BY clause #begin# 另一文章:http://www.cnblogs.com/chinabc/articles/1597198.html 【摘抄】 每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只是最后一步生成的表才会返回 给调用者。如果没有在查询中指定某一子句,将跳过相应的步骤。下面是对应用于SQL server 2000和SQL Server 2005的各个逻辑步骤的简单描述。 ( 8 ) SELECT ( 9 ) DISTINCT ( 11 ) < Top

MySQL优化(二)

╄→гoц情女王★ 提交于 2020-03-30 04:43:53
1、建立基础索引:在where,order,join字段上建立索引 优化,组合索引:基于业务逻辑 前缀索引使用上与普通索引一致! 2、索引的存储结构:Btree索引,hash索引,聚簇索引 Btree不是二叉树 在MySQL中,仅仅只有InnoDB的主键索引是聚簇结构,其他的都是典型的BTree结构 Hash索引就是key-value,就是PHP中的关联数组,索引被载入到内存时 3、queryCache,当数据表结构改动,缓存失效,动态数据不能被缓存 show variables like 'query_cache_type' show variables like 'query_cache_size' set global query_cache_size=102760448; select sql_cache * from student where user like '%fyw' 4、分区,partition 一个表的数据和索引存储在不同文件中 //利用id字段,使用hash算法,将数据分布到10个分区内 partition by hash(id) partitions 10 5、算法 (1)hash算法:(均匀分配) 分区算法,在业务逻辑层面,表示均匀分配。 (2)key算法:(均匀分配) partition by key(subject) partitions 10

MySQL基础篇(07):用户和权限管理,日志体系简介

淺唱寂寞╮ 提交于 2020-03-30 00:51:42
本文源码: GitHub·点这里 || GitEE·点这里 一、MySQL用户 1、基础描述 在数据库的使用过程中,用户作为访问数据库的鉴权因素,起到非常重要的作用,安装MySQL时会自动生成一个root用户,作为数据库管理员,拥有所有权限。在多用户的应用场景下,可能需要给不同的用户分配不同的权限,用来提升系统的稳定性,比如常见:报表库只提供读权限,或者开放给第三方的库,也只提供可读用户。 2、用户管理 基本描述 MySQL将用户信息存储在系统数据库mysql的user表中。根据用户名密码和客户端主机来定义帐户。 用户密码:基本验证操作 ; 客户端IP:类似黑白名单的限制,支持通配符表达式 ; SELECT t.`Host`,t.`User`,t.authentication_string FROM mysql.`user` t ; 添加用户 可以对user表进行增删改查一系列操作,进而添加用户,不同的用户就会涉及到不同的操作权限,这就是另外一个问题:用户的权限管理。 这里添加一个user01用户,作为权限模块的测试用户,权限先给和root用户一样的权限。 INSERT INTO `mysql`.`user`(`Host`, `User`, `authentication_string`) VALUES ('%', 'user01', '

mysql常用命令

拟墨画扇 提交于 2020-03-29 18:40:28
-----创建----- 查看服务器中当前有哪些数据库 mysql> show databases; 选择所使用的数据库 mysql> use 数据库名; 创建数据库 mysql> create database 数据库名; 在当前数据库中创建数据表 mysql> create table 表名 (字段 1 类型 1,...); -----删除----- 删除指定的数据库 mysql> drop database 数据库名; 删除当前或指定数据库中指定的数据表 mysql> drop table 表名; 删除所有记录 mysql> truncate table 表名; 删除字段 mysql> alter table 表名 drop 字段; 在数据表中删除指定的记录 mysql> delete from 表名 where 条件表达式; 将当前数据库表中记录清空 mysql> delete from 表名; 用optimize table来优化一下,只对MyISAM, BDB和InnoDB表起作用。运行过程中,MySQL会锁定表。 mysql> optimize table test.userinfo; -----查看----- 查看服务器中当前有哪些数据库 mysql> show databases; 显示当前数据库中有哪些数据表 mysql> show tables;

《数据库优化》- MySQL优化

瘦欲@ 提交于 2020-03-29 18:31:23
前言   MySQL作为我们最常用的 关系型数据库 ,在开发中,肯定会遇到数据量比较大的情况,而没有足够的性能作为保障,往往查询会比较慢。下面,我们展开来聊聊MySQL怎么优化的。 一、MySQL性能   1、最大数据量   没有数据量和并发数的数据库性能都是没有灵魂的。   MySQL没有限制 单表最大记录数 ,它取决于操作系统对文件大小的限制。   《阿里巴巴Java开发手册》推荐:单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。   性能由综合因素决定,抛开业务复杂度,影响程度依次是: 硬件配置、MySQL配置、数据表设计、索引优化 。 500万这个值仅供参考,并非铁律。   有位大佬操作过超过4亿行数据的单表,分页查询最新的20条记录耗时0.6秒。   SQL大致是: select field_1,field_2 from table where id < #{prePageMinId} order by id desc limit 20 ;   prePageMinId是上一页数据记录的最小ID。   虽然当时查询速度还凑合,随着数据不断增长,有朝一日必定不堪重负。   分库分表是个周期长而风险高的大活儿,应该尽可能在当前结构上优化,比如升级硬件、迁移历史数据等等,实在没辙了再分。对分库分表感兴趣的同学可以阅读分库分表的基本思想。      2

数据库原理及操作

不羁岁月 提交于 2020-03-29 17:34:06
数据库基础 传统的文件系统管理的缺陷 编写应用程序不方便; 数据冗余不可避免; 应用程序依赖性; 不支持对文件的并发访问; 数据间联系弱 难以按用户视图表示数据; 无阶段性安全控制功能。 数据库管理系统的优点 相互关联的数据的集合; 较少的数据冗余; 程序与数据相互独立; 保证数据的安全、可靠; 最大限度地保证数据的正确性; 数据可以并发使用并能同时保证一致性。 数据库管理系统 数据库是数据的汇集,它以一定的组织形式存在于存储介质上 DBMS是管理数据库的系统软件,它实现数据库系统的各种功能。是数据库系统的核心 DBA: 负责数据库的规划、设计、协调、维护和管理等工作 应用程序指以数据库为基础的应用程序; 关系型数据Key/Value 数据库 关系:关系就是二维表。并满足如下性质: 表中的行、列次序并不在重要 行row:表中的每一行,又称为一条记录(record) 列column:表中的没一列,称为属性,字段 主键(Primary key):用于唯一确定一个记录的字段 域domain:属性的取值范围,如,性别只能是‘男’和‘女’两个值 外键(Foreign key):用于表之间的一对多的关系 唯一键(Uniq key):可以为null, 非关系型数据库:NO SQL(not only SQL) mencached redis mogoDB RDBMS MySQL: MySQL,

MySQL数据库存储引擎

孤者浪人 提交于 2020-03-29 01:22:06
这里主要介绍最常用的两种存储引擎。 1.InnoDB InnoDB是一个事务型的存储引擎,有行级锁定和外键约束。 Innodb引擎提供了对数据库ACID事务的支持,并且实现了SQL标准的四种隔离级别,关于数据库事务与其隔离级别的内容请见数据库事务与其隔离级别这类型的文章。该引擎还提供了行级锁和外键约束,它的设计目标是处理大容量数据库系统,它本身其实就是基于MySQL后台的完整数据库系统,MySQL运行时Innodb会在内存中建立缓冲池,用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引,而且它没有保存表的行数,当SELECT COUNT(*) FROM TABLE时需要扫描全表。当需要使用数据库事务时,该引擎当然是首选。由于锁的粒度更小,写操作不会锁定全表,所以在并发较高时,使用Innodb引擎会提升效率。但是使用行级锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表。 适用场景: 1)经常更新的表,适合处理多重并发的更新请求。 2)支持事务。 3)可以从灾难中恢复(通过bin-log日志等)。 4)外键约束。只有他支持外键。 5)支持自动增加列属性auto_increment。 2.MyIsam MyIASM是MySQL默认的引擎,但是它没有提供对数据库事务的支持,也不支持行级锁和外键,因此当INSERT(插入

一条SQL查询语句是如何执行的?

不想你离开。 提交于 2020-03-28 17:47:49
导读 Mysql在中小型企业中是个香饽饽,目前主流的数据库之一,几乎没有一个后端开发者不会使用的,但是作为一个老司机,仅仅会用真的不够。 今天陈某透过一个简单的查询语句来讲述在Mysql内部的执行过程。 select * from table where id=10;    撸它 首先通过一张图片来了解一下Mysql的基础架构,如下: 从上图可以看出,Mysql大致分为Server层和存储引擎层两部分。 Server层包括 连接器 、 查询缓存 、 分析器 、 优化器 等,其中包含了Mysql的大多数核心功能以及所有的内置函数(如日期,时间函数等),所有跨存储引擎的功能都在这一层实现,比如 存储过程 、 触发器 、 视图 等。 存储引擎层负责数据的存储和提取。它的架构是可插拔式的,支持 InnoDB 、 MyISAM 等多个存储引擎。Mysql中主流的存储引擎是InnoDB,由于它对事务的支持让它从Mysql5.5.5版本开始成为了默认的存储引擎。 大致了解了整体架构,现在说说每一个基础的模块都承担着怎样的责任。 1. 连接器 顾名思义,是客户端和Mysql之间连接的媒介, 负责登录、获取权限、维持连接和管理连接 。连接命令一般如下: mysql [-h] ip [- P] port -u [user] -p 在完成经典的TCP握手后,连接器会开始认证身份,要求输入密码。

知名网站的技术发展历程

非 Y 不嫁゛ 提交于 2020-03-28 10:03:35
互联网已经发展多年,其中不乏脱颖而出者,这些网站多数都已存在了接近 10 年或 10 年以上,在如此长时间的发展过程中,除了业务上面临的挑战,在技术上也面临了很多的挑战。 我挑选了一些 Alexa 排名较前的网站 ( 排名截止到 2012 年 4 月 21 日),看看它们在技术上是如何应对业务发展过程中的挑战的。 Google 目前 Alexa 排名第 1 。它诞生于 1997 年,当时是一个研究性项目,每个月 build 一次索引, build 出来的索引通过 sharding ( shard by doc )的方式分散到多台服务器( Index Server )上,具体的网页数据同样通过 sharding 的方式分散到多台服务器( Doc Server )上,当用户提交请求时,通过前端的一台服务器将请求提交给 Index Server 获得打了分的倒排索引,然后从 Doc Server 提取具体的网页信息(例如网页标题、搜索关键词匹配的片段信息等),最终展现给用户。 随着索引的网页增加,这个结构可通过增加 Index Server 以及 Doc Server 来存储索引以及网页的数据,但仍然会面临其他很多方面的问题,于是在这之后的十多年的时间里, Google 做了很多事情来改进上面的结构。 1999 年, Google 增加了一个 Cache Cluster ,用来