数据库性能

前言 优化有风险，涉足需谨慎！！！ 1、优化可能带来的问题？ 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过我们可能没有能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题，控制在可接受的范围内才是有成果，保持现状或出现更差的情况都是失败。 2、优化的需求 稳定性和业务的持续性，通常比性能更重要。 优化不可避免涉及到变更，变更就有风险。 优化使性能变好，维持和变差使等概率事件。 切记优化，应该是各部门协同参与的工作，任何单一部门都不能对数据库进行优化。 所有优化工作，是由业务需要驱使的。 3、优化由谁参与 在进行数据库优化时，应该由DBA、业务部门代表、应用程序设计人员、应用程序开发人员、运维等相关人员共同参与。 4、优化思路 在数据库优化上由两个主要方面：即安全与性能。 安全：数据可持续性。 性能：数据的高性能访问。 5、优化的范围有哪些？ 存储、主机和操作系统方面： 主机架构稳定性； I/O规划及配置； Swap交换分区； OS内核参数和网络问题； 应用程序方面； 应用程序稳定性； SQL语句性能； 串行访问资源； 性能欠佳会话管理； 这个应用适不适合用MySQL； 数据库优化方面： 内存； 数据库结构（物理&逻辑）； 实例配置； 注：不管是在设计系统

第1章 数据库介绍与分类 1.1 数据库介绍 什么是数据库 简单的说，数据库就是一个存放计算机数据的仓库，这个仓库是按照一定的数据结构（数据结构是指数据的组织形式或数据之间的联系）来对数据进行组织和存储的，我们可以通过数据库提供的多种方法来管理其中的数据。 1.2 数据库的种类 按照早期的数据库理论，比较流行的数据库模型有三种，分别为层次式数据库、网状数据库和关系型数据库。而在当今的互联网企业中，最常用的数据库模式主要有两种，即关系型数据库和非关系型数据库。 1.2.1 关系型数据库介绍 （1）关系型数据库由来 虽然网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但是在数据独立和抽象级别上仍有很大欠缺。用户在对这两种数据库进行存取时，仍然需要明确数据的存储结构，指出存取路径。而关系数据库就可以比较好地解决这些问题。 （2）关系型数据库介绍 关系型数据库模型是把复杂的数据结构归结为简单的二元关系（即二维表格形式）。在关系型数据库中，对数据的操作几乎全部建立在一个或多个关系表格上，通过这些关联的表格分类、合并、连接或选取等运算来实现数据的管理。 关系型数据库诞生距今已有40多年了，从理论产生到发展到实现产品，例如：常见的MySQL和Oracle数据库，oracle在数据库领域里上升到了霸主地位，形成每年高达数百亿美元的庞大产业市场，而MySQL也是不容忽视的数据库

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

现在Redis越来越火，为了适应技术的发展，开始学习一下Redis，在学习Redis之前先学习一下Nosql。 第一部分：入门概述 1.1 互联网时代背景下大机遇，为什么用nosql 1.1.1 单机Mysql的美好年代（好几年前） 当时的业务很相对简单，就是JSP--->Action---->Service---->DAO----->数据库，数据库也就是一个实例而已，无论是Mysql还是Oracle。把这五层缩减为三层的话便是：应用层------>DAO层------>Mysql实例。 以前一个网站的访问量一般不大，用单个数据库可以轻松应付。但是随着时代的发展，上述数据存储遇到了存储的瓶颈： 1) 数据量的总大小，一个机器放不下时(以Mysql为例，单表存储大概三百多万的数据的时候DBA就该进行预警并优化分割了) 2) 数据的索引(B+Tree)，一个机器的内存放不下时(众所周知，为表建立索引也是需要消耗内存的，当我们所建立的索引内存盛不下时) 3) 访问量（读写混合）一个实例不能承受 1.1.2 Memcached(缓存)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引

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

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

本文由云+社区发表 作者：数据库 版权声明： 本文由腾讯云数据库产品团队整理，页面原始内容来自于severalnines英文官网，若转载请注明出处。翻译目的在于传递更多全球最新数据库领域相关信息，并不意味着腾讯云数据库产品团队赞同其观点或证实其内容的真实性。如果其他媒体、网站或其他任何形式的法律实体和个人使用，必须经过著作权人合法书面授权并自负全部法律责任。不得擅自使用腾讯云数据库团队的名义进行转载，或盗用腾讯云数据库团队名义发布信息。 原文链接：https://severalnines.com/blog/mysql-performance-benchmarking-mysql-57-vs-mysql-80 在Oracle MySQL团队的推动下，MySQL 8.0发生了巨大的变化和修改。 物理文件已更改。例如， .frm， .TRG， .TRN和 .par 不再存在。添加了大量的新特性，如通用表表达式(Common Table Expressions CTE)，窗口函数（Window Functions），不可见索引（ Invisible Indexes），正则表达式（regexp） -MySQL8.0现在已经完全支持Unicode，且具有多字节安全特性。数据字典也发生了变化。它现在与一个事务性数据字典合并，该字典存储有关数据库对象的信息。与以前的版本不同

一、SQL Server基本简介 1.1，概述 SQL Server 是Microsoft 公司推出的关系型数据库管理系统。具有使用方便可伸缩性好与相关软件集成程度高等优点，可跨越从运行Microsoft Windows 98 的膝上型电脑到运行Microsoft Windows 2012 的大型多处理器的服务器等多种平台使用。 Microsoft SQL Server 是一个全面的数据库平台，使用集成的商业智能 (BI)工具提供了企业级的数据管理。Microsoft SQL Server 数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能，使您可以构建和管理用于业务的高可用和高性能的数据应用程序。 1.2，应用范围 SQL Server的应用范围，和其具体的版本有一定的关系，基本上是：企业版（Enterprise Edition） （大中型企业商用）；标准版（Standard Edition） （小型企业商用）；开发版（Developer Edition） （开发公司、开发人员使用）；个人版（Personal Edition） （开发人员使用）；MSDE 2000（Microsoft SQL Server 2000 Desktop Engine）（简单的单机数据库、开发人员开发测试使用） 1.3，优缺点 (1) 扩展性强：当系统要更高数据库处理速度时

文章目录 1.数据模型 2.关系模型与非关系模型 2.1 关系模型、文档模型与图模型 2.2 层次模型的局限与演化 2.3 文档数据库的模式灵活性与数据局部性 读时模式 VS 写时模式 数据局部性的优缺点 2.4 MapReduce查询 3. 图模型 3.1 属性图模型和Cypher查询语言 属性图的基本概念 3.2 三元存储模型与SPARQL查询语言 RDF数据模型 SPARQL查询语言 3.3 一阶谓词逻辑表示法与Datalog 一阶谓词逻辑 Prolog语言 3.4 图数据库与网络模型的比较 1.数据模型 大多数应用程序是通过一层一层叠加数据模型来构建的，每一层都面临的关键问题是：如何将其用下一层来表示？例如： 1. 观察现实世界，通过构建对象或数据结构，以及操作这些数据结构的API来对其建模。 2. 采用通用数据模型，存储这些数据结构。 3. 数据库工程师决定用何种内存、磁盘或网络的字节格式来表示上述数据。 4. 更下层，硬件工程师考虑如何用电流、磁场、光脉冲等来表示字节。 基本思想相同：每层都通过提供一个简洁的数据模型来隐藏下层的复杂性。这种抽象机制使得不同的人群可以高效协作。 2.关系模型与非关系模型 关于NoSQL的介绍，与SQL的对比，没有比这个介绍更准确详细了，请参照菜鸟教程： NoSQL简介 本书中主要介绍和研究的非关系模型是：文档模型、图模型