不是mysql5.6新特性 nosql
成都创新互联公司专业提供成都主机托管四川主机托管成都服务器托管四川服务器托管，支持按月付款！我们的承诺：贵族品质、平民价格，机房位于中国电信/网通/移动机房，成都服务器托管服务有保障！
下载白皮书：MySQL 5.6 中的新特性 »
MySQL 5.6 显著提高了性能和可用性，可支持下一代 Web、嵌入式和云计算应用程序。
MySQL Database 5.6 具备以下特性：
新增！ 在线 DDL /更改数据架构支持动态应用程序和开发人员灵活性
新增！ 复制全局事务标识可支持自我修复式集群
新增！ 复制无崩溃从机可提高可用性
新增！ 复制多线程从机可提高性能
新增！ 对 InnoDB 进行 NoSQL 访问，可快速完成键值操作以及快速提取数据来完成大数据部署
改进！ 在 Linux 上的性能提升多达 230%
改进！ 在当今、多核、多 CPU 硬件上具备更高的扩展力
改进！ InnoDB 性能改进，可更加高效地处理事务和只读负载
改进！ 更快速地执行查询，增强的诊断功能
改进！ Performance Schema 可监视各个用户/应用程序的资源占用情况
改进！ 通过基于策略的密码管理和实施来确保安全性
高度可靠，几乎无需干预即可确保系统持续不间断运行
简便易用，只需 3 分钟即可完成从下载到开发环境的安装和配置过程
管理需求低，数据库维护工作非常少
复制功能 支持灵活的拓扑架构，可实现向外扩展和高可用性
分区 有助于提高性能和管理超大型数据库环境
ACID 事务 支持构建安全可靠的关键业务应用程序
存储过程 可提高开发人员效率
触发器 可在数据库层面实施复杂的业务规则
View 可确保敏感信息不受攻击
Information Schema 有助于方便地访问元数据
插入式存储引擎架构 可最大限度发挥灵活性
oSQL与关系型数据库设计理念比较
关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。
特点：
它们可以处理超大量的数据。
它们运行在便宜的PC服务器集群上。
它们击碎了性能瓶颈。
没有过多的操作。
Bootstrap支持
缺点：
但是一些人承认，没有正式的官方支持，万一出了差错会是可怕的，至少很多管理人员是这样看。
此外，nosql并未形成一定标准，各种产品层出不穷，内部混乱，各种项目还需时间来检验
前言:
MYSQL 应该是最流行了 WEB 后端数据库。虽然 NOSQL 最近越来越多的被提到，但是相信大部分架构师还是会选择 MYSQL 来做数据存储。本文作者总结梳理MySQL性能调优的15个重要变量，又不足需要补充的还望大佬指出。
1.DEFAULT_STORAGE_ENGINE
如果你已经在用MySQL 5.6或者5.7，并且你的数据表都是InnoDB，那么表示你已经设置好了。如果没有，确保把你的表转换为InnoDB并且设置default_storage_engine为InnoDB。
为什么？简而言之，因为InnoDB是MySQL(包括Percona Server和MariaDB)最好的存储引擎 – 它支持事务，高并发，有着非常好的性能表现(当配置正确时)。这里有详细的版本介绍为什么
2.INNODB_BUFFER_POOL_SIZE
这个是InnoDB最重要变量。实际上，如果你的主要存储引擎是InnoDB，那么对于你，这个变量对于MySQL是最重要的。
基本上，innodb_buffer_pool_size指定了MySQL应该分配给InnoDB缓冲池多少内存，InnoDB缓冲池用来存储缓存的数据，二级索引，脏数据(已经被更改但没有刷新到硬盘的数据)以及各种内部结构如自适应哈希索引。
根据经验，在一个独立的MySQL服务器应该分配给MySQL整个机器总内存的80%。如果你的MySQL运行在一个共享服务器，或者你想知道InnoDB缓冲池大小是否正确设置，详细请看这里。
3.INNODB_LOG_FILE_SIZE
InnoDB重做日志文件的设置在MySQL社区也叫做事务日志。直到MySQL 5.6.8事务日志默认值innodb_log_file_size=5M是唯一最大的InnoDB性能杀手。从MySQL 5.6.8开始，默认值提升到48M,但对于许多稍繁忙的系统，还远远要低。
根据经验，你应该设置的日志大小能在你服务器繁忙时能存储1-2小时的写入量。如果不想这么麻烦，那么设置1-2G的大小会让你的性能有一个不错的表现。这个变量也相当重要，更详细的介绍请看这里。
当然，如果你有大量的大事务更改，那么，更改比默认innodb日志缓冲大小更大的值会对你的性能有一定的提高，但是你使用的是autocommit，或者你的事务更改小于几k，那还是保持默认的值吧。
4.INNODB_FLUSH_LOG_AT_TRX_COMMIT
默认下，innodb_flush_log_at_trx_commit设置为1表示InnoDB在每次事务提交后立即刷新同步数据到硬盘。如果你使用autocommit，那么你的每一个INSERT, UPDATE或DELETE语句都是一个事务提交。
同步是一个昂贵的操作(特别是当你没有写回缓存时)，因为它涉及对硬盘的实际同步物理写入。所以如果可能，并不建议使用默认值。
两个可选的值是0和2:
* 0表示刷新到硬盘，但不同步(提交事务时没有实际的IO操作)
* 2表示不刷新和不同步(也没有实际的IO操作)
所以你如果设置它为0或2，则同步操作每秒执行一次。所以明显的缺点是你可能会丢失上一秒的提交数据。具体来说，你的事务已经提交了，但服务器马上断电了，那么你的提交相当于没有发生过。
显示的，对于金融机构，如银行，这是无法忍受的。不过对于大多数网站，可以设置为innodb_flush_log_at_trx_commit=0|2，即使服务器最终崩溃也没有什么大问题。毕竟，仅仅在几年前有许多网站还是用MyISAM，当崩溃时会丢失30s的数据(更不要提那令人抓狂的慢修复进程)。
那么，0和2之间的实际区别是什么？性能明显的差异是可以忽略不计，因为刷新到操作系统缓存的操作是非常快的。所以很明显应该设置为0，万一MySQL崩溃(不是整个机器)，你不会丢失任何数据，因为数据已经在OS缓存，最终还是会同步到硬盘的。
5.SYNC_BINLOG
已经有大量的文档写到sync_binlog，以及它和innodb_flush_log_at_trx_commit的关系，下面我们来简单的介绍下：
a) 如果你的服务器没有设置从服务器，而且你不做备份，那么设置sync_binlog=0将对性能有好处。
b) 如果你有从服务器并且做备份，但你不介意当主服务器崩溃时在二进制日志丢失一些事件，那么为了更好的性能还是设置为sync_binlog=0.
c) 如果你有从服务器并且备份，你非常在意从服务器的一致性，以及能及时恢复到一个时间点(通过使用最新的一致性备份和二进制日志将数据库恢复到特定时间点的能力)，那么你应该设置innodb_flush_log_at_trx_commit=1，并且需要认真考虑使用sync_binlog=1。
问题是sync_binlog=1代价比较高 – 现在每个事务也要同步一次到硬盘。你可能会想为什么不把两次同步合并成一次，想法正确 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已经能合并提交，那么在这种情况下sync_binlog=1的操作也不是这么昂贵了，但在旧的mysql版本中仍然会对性能有很大影响。
6.INNODB_FLUSH_METHOD
将innodb_flush_method设置为O_DIRECT以避免双重缓冲.唯一一种情况你不应该使用O_DIRECT是当你操作系统不支持时。但如果你运行的是Linux，使用O_DIRECT来激活直接IO。
不用直接IO，双重缓冲将会发生，因为所有的数据库更改首先会写入到OS缓存然后才同步到硬盘 – 所以InnoDB缓冲池和OS缓存会同时持有一份相同的数据。特别是如果你的缓冲池限制为总内存的50%，那意味着在写密集的环境中你可能会浪费高达50%的内存。如果没有限制为50%，服务器可能由于OS缓存的高压力会使用到swap。
简单地说，设置为innodb_flush_method=O_DIRECT。
7.INNODB_BUFFER_POOL_INSTANCES
MySQL 5.5引入了缓冲实例作为减小内部锁争用来提高MySQL吞吐量的手段。
在5.5版本这个对提升吞吐量帮助很小，然后在MySQL 5.6版本这个提升就非常大了，所以在MySQL5.5中你可能会保守地设置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以设置为8-16个缓冲池实例。
你设置后观察会觉得性能提高不大，但在大多数高负载情况下，它应该会有不错的表现。
对了，不要指望这个设置能减少你单个查询的响应时间。这个是在高并发负载的服务器上才看得出区别。比如多个线程同时做许多事情。
8.INNODB_THREAD_CONCURRENCY
InnoDB有一种方法来控制并行执行的线程数 – 我们称为并发控制机制。大部分是由innodb_thread_concurrency值来控制的。如果设置为0，并发控制就关闭了，因此InnoDB会立即处理所有进来的请求(尽可能多的)。
在你有32CPU核心且只有4个请求时会没什么问题。不过想像下你只有4CPU核心和32个请求时 – 如果你让32个请求同时处理，你这个自找麻烦。因为这些32个请求只有4 CPU核心，显然地会比平常慢至少8倍(实际上是大于8倍)，而然这些请求每个都有自己的外部和内部锁，这有很大可能堆积请求。
下面介绍如何更改这个变量，在mysql命令行提示符执行：
对于大多数工作负载和服务器，设置为8是一个好开端，然后你可以根据服务器达到了这个限制而资源使用率利用不足时逐渐增加。可以通过show engine innodb status\G来查看目前查询处理情况，查找类似如下行：
9.SKIP_NAME_RESOLVE
这一项不得不提及，因为仍然有很多人没有添加这一项。你应该添加skip_name_resolve来避免连接时DNS解析。
大多数情况下你更改这个会没有什么感觉，因为大多数情况下DNS服务器解析会非常快。不过当DNS服务器失败时，它会出现在你服务器上出现“unauthenticated connections” ，而就是为什么所有的请求都突然开始慢下来了。
所以不要等到这种事情发生才更改。现在添加这个变量并且避免基于主机名的授权。
10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX
* innodb_io_capacity：用来当刷新脏数据时，控制MySQL每秒执行的写IO量。
* innodb_io_capacity_max: 在压力下，控制当刷新脏数据时MySQL每秒执行的写IO量
首先，这与读取无关 – SELECT查询执行的操作。对于读操作，MySQL会尽最大可能处理并返回结果。至于写操作，MySQL在后台会循环刷新，在每一个循环会检查有多少数据需要刷新，并且不会用超过innodb_io_capacity指定的数来做刷新操作。这也包括更改缓冲区合并（在它们刷新到磁盘之前，更改缓冲区是辅助脏页存储的关键）。
第二，我需要解释一下什么叫“在压力下”，MySQL中称为”紧急情况”，是当MySQL在后台刷新时，它需要刷新一些数据为了让新的写操作进来。然后，MySQL会用到innodb_io_capacity_max。
那么，应该设置innodb_io_capacity和innodb_io_capacity_max为什么呢？
最好的方法是测量你的存储设置的随机写吞吐量，然后给innodb_io_capacity_max设置为你的设备能达到的最大IOPS。innodb_io_capacity就设置为它的50-75%，特别是你的系统主要是写操作时。
通常你可以预测你的系统的IOPS是多少。例如由8 15k硬盘组成的RAID10能做大约每秒1000随机写操作，所以你可以设置innodb_io_capacity=600和innodb_io_capacity_max=1000。许多廉价企业SSD可以做4,000-10,000 IOPS等。
这个值设置得不完美问题不大。但是，要注意默认的200和400会限制你的写吞吐量，因此你可能偶尔会捕捉到刷新进程。如果出现这种情况，可能是已经达到你硬盘的写IO吞吐量，或者这个值设置得太小限制了吞吐量。
11.INNODB_STATS_ON_METADATA
如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默认值，因为它已经设置正确了。
不过在MySQL 5.5或5.1，强烈建议关闭这个变量 – 如果是开启，像命令show table status会立即查询INFORMATION_SCHEMA而不是等几秒再执行，这会使用到额外的IO操作。
从5.1.32版本开始，这个是动态变量，意味着你不需要重启MySQL服务器来关闭它。
12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN INNODB_BUFFER_POOL_LOAD_AT_STARTUP
innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup这两个变量与性能无关，不过如果你偶尔重启mysql服务器(如生效配置)，那么就有关。当两个都激活时，MySQL缓冲池的内容(更具体地说，是缓存页)在停止MySQL时存储到一个文件。当你下次启动MySQL时，它会在后台启动一个线程来加载缓冲池的内容以提高预热速度到3-5倍。
两件事：
第一，它实际上没有在关闭时复制缓冲池内容到文件，仅仅是复制表空间ID和页面ID – 足够的信息来定位硬盘上的页面了。然后它就能以大量的顺序读非常快速的加载那些页面，而不是需要成千上万的小随机读。
第二，启动时是在后台加载内容，因为MySQL不需要等到缓冲池内容加载完成再开始接受请求(所以看起来不会有什么影响)。
从MySQL 5.7.7开始，默认只有25%的缓冲池页面在mysql关闭时存储到文件，但是你可以控制这个值 – 使用innodb_buffer_pool_dump_pct，建议75-100。
这个特性从MySQL 5.6才开始支持。
13.INNODB_ADAPTIVE_HASH_INDEX_PARTS
如果你运行着一个大量SELECT查询的MySQL服务器(并且已经尽可能优化)，那么自适应哈希索引将下你的下一个瓶颈。自适应哈希索引是InnoDB内部维护的动态索引，可以提高最常用的查询模式的性能。这个特性可以重启服务器关闭，不过默认下在mysql的所有版本开启。
这个技术非常复杂，在大多数情况下它会对大多数类型的查询直到加速的作用。不过，当你有太多的查询往数据库，在某一个点上它会花过多的时间等待AHI锁和闩锁。
如果你的是MySQL 5.7，没有这个问题 – innodb_adaptive_hash_index_parts默认设置为8，所以自适应哈希索引被切割为8个分区，因为不存在全局互斥。
不过在mysql 5.7前的版本，没有AHI分区数量的控制。换句话说，有一个全局互斥锁来保护AHI，可能导致你的select查询经常撞墙。
所以如果你运行的是5.1或5.6，并且有大量的select查询，最简单的方案就是切换成同一版本的Percona Server来激活AHI分区。
14.QUERY_CACHE_TYPE
如果人认为查询缓存效果很好，肯定应该使用它。好吧，有时候是有用的。不过这个只在你在低负载时有用，特别是在低负载下大多数是读取，小量写或者没有。
如果是那样的情况，设置query_cache_type=ON和query_cache_size=256M就好了。不过记住不能把256M设置更高的值了，否则会由于查询缓存失效时，导致引起严重的服务器停顿。
如果你的MySQL服务器高负载动作，建议设置query_cache_size=0和query_cache_type=OFF，并重启服务器生效。那样Mysql就会停止在所有的查询使用查询缓存互斥锁。
15.TABLE_OPEN_CACHE_INSTANCES
从MySQL 5.6.6开始，表缓存能分割到多个分区。
表缓存用来存放目前已打开表的列表，当每一个表打开或关闭互斥体就被锁定 – 即使这是一个隐式临时表。使用多个分区绝对减少了潜在的争用。
从MySQL 5.7.8开始，table_open_cache_instances=16是默认的配置。
欢迎做Java的工程师朋友们私信我资料免费获取免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）
其中覆盖了互联网的方方面面，期间碰到各种产品各种场景下的各种问题，很值得大家借鉴和学习，扩展自己的技术广度和知识面。
NoSQL 数据库因其功能性、易于开发性和可扩展性而广受认可，它们越来越多地用于大数据和实时 Web 应用程序，在本文中，我们通过示例讨论 NoSQL、何时使用 NoSQL 与 SQL 及其用例。
NoSQL是一种下一代数据库管理系统 (DBMS)。NoSQL 数据库具有灵活的模式，可用于构建具有大量数据和高负载的现代应用程序。
“NoSQL”一词最初是由 Carlo Strozzi 在 1998 年创造的，尽管自 1960 年代后期以来就已经存在类似的数据库。然而，NoSQL 的发展始于 2009 年初，并且发展迅速。
在处理大量数据时，任何关系数据库管理系统 (RDBMS) 的响应时间都会变慢。为了解决这个问题，我们可以通过升级现有硬件来“扩大”信息系统，这非常昂贵。但是，NoSQL 可以更好地横向扩展并且更具成本效益。
NoSQL 对于非结构化或非常大的数据对象（例如聊天日志数据、视频或图像）非常有用，这就是为什么 NoSQL 在微软、谷歌、亚马逊、Meta (Facebook) 等互联网巨头中特别受欢迎的原因。
一些流行的 NoSQL 数据库包括：
随着企业更快地积累更大的数据集，结构化数据和关系模式并不总是适合。有必要使用非结构化数据和大型对象来更好地捕获这些信息。
传统的 RDBMS 使用 SQL（结构化查询语言）语法来存储和检索结构化数据，相反，NoSQL 数据库包含广泛的功能，可以存储和检索结构化、半结构化、非结构化和多态数据。
有时，NoSQL 也被称为“ 不仅仅是 SQL ”，强调它可能支持类似 SQL 的语言或与 SQL 数据库并列。SQL 和 NoSQL DBMS 之间的一个区别是 JOIN 功能。SQL 数据库使用 JOIN 子句来组合来自两个或多个表的行，因为 NoSQL 数据库本质上不是表格的，所以这个功能并不总是可行或相关的。
但是，一些 NoSQL DBMS 可以执行类似于 JOIN的操作——就像 MongoDB 一样。这并不意味着不再需要 SQL DBMS，相反，NoSQL 和 SQL 数据库倾向于以不同的方式解决类似的问题。
一般来说，在以下情况下，NoSQL 比 SQL 更可取：
许多行业都在采用 NoSQL，取代关系数据库，从而为某些业务应用程序提供更高的灵活性和可扩展性，下面给出了 NoSQL 数据库的一些企业用例。
内容管理是一组用于收集、管理、传递、检索和发布任何格式的信息的过程，包括文本、图像、音频和视频。NoSQL 数据库可以通过其灵活和开放的数据模型为存储多媒体内容提供更好的选择。
例如，福布斯在短短几个月内就构建了一个基于 MongoDB 的定制内容管理系统，以更低的成本为他们提供了更大的敏捷性。
大数据是指太大而无法通过传统处理系统处理的数据集，实时存储和检索大数据的系统在分析 历史 数据的同时使用流处理来摄取新数据，这是一系列非常适合 NoSQL 数据库的功能。
Zoom使用 DynamoDB（按需模式）使其数据能够在没有性能问题的情况下进行扩展，即使该服务在 COVID-19 大流行的早期使用量激增。
物联网设备具有连接到互联网或通信网络的嵌入式软件和传感器，能够在无需人工干预的情况下收集和共享数据。随着数十亿台设备生成数不清的数据，IoT NoSQL 数据库为 IoT 服务提供商提供了可扩展性和更灵活的架构。
Freshub就是这样的一项服务，它从 MySQL 切换到 MongoDB，以更好地处理其大型、动态、非统一的数据集。
拥有数十亿智能手机用户，可扩展性正成为在移动设备上提供服务的企业面临的最大挑战。具有更灵活数据模型的 NoSQL DBMS 通常是完美的解决方案。
例如，The Weather Channel使用 MongoDB 数据库每分钟处理数百万个请求，同时还处理用户数据并提供天气更新。
通常来说，当数据多、并发量大的时候，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他数据库)的压力，但不是使用Redis，就不用MySQL。
因为Redis的性能十分优越，可以支持每秒十几万此的读/写操作，并且它还支持持久化、集群部署、分布式、主从同步等，Redis在高并发的场景下数据的安全和一致性，所以它经常用于两个场景：
缓存
判断数据是否适合缓存到Redis中，可以从几个方面考虑： 会经常查询么？命中率如何？写操作多么？数据大小？
我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。
缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。
高速读写
常见的就是计数器，比如一篇文章的阅读量，不可能每一次阅读就在数据库里面update一次。
高并发的场景很适合使用Redis，比如双11秒杀，库存一共就一千件，到了秒杀的时间，通常会在极为短暂的时间内，有数万级的请求达到服务器，如果使用数据库的话，很可能在这一瞬间造成数据库的崩溃，所以通常会使用Redis（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）。
这种高并发的场景，是当请求达到服务器的时候，直接在Redis上读写，请求不会访问到数据库；程序会在合适的时间，比如一千件库存都被秒杀，再将数据批量写到数据库中。
所以通常来说，在必要的时候引入Redis，可以减少MySQL（或其他）数据库的压力，两者不是替代的关系 。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
Redis和MySQL的应用场景是不同的。
通常来说，没有说用Redis就不用MySQL的这种情况。
因为Redis是一种非关系型数据库（NoSQL），而MySQL是一种关系型数据库。
和Redis同类的数据库还有MongoDB和Memchache（其实并没有持久化数据）
那关系型数据库现在常用的一般有MySQL，SQL Server，Oracle。
我们先来了解一下关系型数据库和非关系型数据库的区别吧。
1.存储方式
关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。
2.存储结构
关系型数据库对应的是结构化数据，数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。这一点对数据建模至关重要，虽然预定义结构带来了可靠性和稳定性，但是修改这些数据比较困难。而Nosql数据库基于动态结构，使用与非结构化数据。因为Nosql数据库是动态结构，可以很容易适应数据类型和结构的变化。
3.存储规范
关系型数据库的数据存储为了更高的规范性，把数据分割为最小的关系表以避免重复，获得精简的空间利用。虽然管理起来很清晰，但是单个操作设计到多张表的时候，数据管理就显得有点麻烦。而Nosql数据存储在平面数据集中，数据经常可能会重复。单个数据库很少被分隔开，而是存储成了一个整体，这样整块数据更加便于读写
4.存储扩展
这可能是两者之间最大的区别，关系型数据库是纵向扩展，也就是说想要提高处理能力，要使用速度更快的计算机。因为数据存储在关系表中，操作的性能瓶颈可能涉及到多个表，需要通过提升计算机性能来克服。虽然有很大的扩展空间，但是最终会达到纵向扩展的上限。而Nosql数据库是横向扩展的，它的存储天然就是分布式的，可以通过给资源池添加更多的普通数据库服务器来分担负载。
5.查询方式
关系型数据库通过结构化查询语言来操作数据库（就是我们通常说的SQL）。SQL支持数据库CURD操作的功能非常强大，是业界的标准用法。而Nosql查询以块为单元操作数据，使用的是非结构化查询语言（UnQl），它是没有标准的。关系型数据库表中主键的概念对应Nosql中存储文档的ID。关系型数据库使用预定义优化方式（比如索引）来加快查询操作，而Nosql更简单更精确的数据访问模式。
6.事务
关系型数据库遵循ACID规则（原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)），而Nosql数据库遵循BASE原则（基本可用（Basically Availble）、软/柔性事务（Soft-state ）、最终一致性（Eventual Consistency））。由于关系型数据库的数据强一致性，所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制，并且易于回滚事务。而Nosql数据库是在CAP（一致性、可用性、分区容忍度）中任选两项，因为基于节点的分布式系统中，很难全部满足，所以对事务的支持不是很好，虽然也可以使用事务，但是并不是Nosql的闪光点。
7.性能
关系型数据库为了维护数据的一致性付出了巨大的代价，读写性能比较差。在面对高并发读写性能非常差，面对海量数据的时候效率非常低。而Nosql存储的格式都是key-value类型的，并且存储在内存中，非常容易存储，而且对于数据的 一致性是 弱要求。Nosql无需sql的解析，提高了读写性能。
8.授权方式
大多数的关系型数据库都是付费的并且价格昂贵，成本较大（MySQL是开源的，所以应用的场景最多），而Nosql数据库通常都是开源的。
所以，在实际的应用环境中，我们一般会使用MySQL存储我们的业务过程中的数据，因为这些数据之间的关系比较复杂，我们常常会需要在查询一个表的数据时候，将其他关系表的数据查询出来，例如，查询某个用户的订单，那至少是需要用户表和订单表的数据。
查询某个商品的销售数据，那可能就会需要用户表，订单表，订单明细表，商品表等等。
而在这样的使用场景中，我们使用Redis来存储的话，也就是KeyValue形式存储的话，其实并不能满足我们的需要。
即使Redis的读取效率再高，我们也没法用。
但，对于某些没有关联少，且需要高频率读写，我们使用Redis就能够很好的提高整个体统的并发能力。
例如商品的库存信息，我们虽然在MySQL中会有这样的字段，但是我们并不想MySQL的数据库被高频的读写，因为使用这样会导致我的商品表或者库存表IO非常高，从而影响整个体统的效率。
所以，对于这样的数据，且有没有什么复杂逻辑关系（就只是隶属于SKU）的数据，我们就可以放在Redis里面，下单直接在Redis中减掉库存，这样，我们的订单的并发能力就能够提高了。
个人觉得应该站出来更正一下，相反的数据量大，更不应该用redis。
为什么？
因为redis是内存型数据库啊，是放在内存里的。
设想一下，假如你的电脑100G的资料，都用redis来存储，那么你需要100G以上的内存！
使用场景
Redis最明显的用例之一是将其用作缓存。只是保存热数据，或者具有过期的cache。
例如facebook，使用Memcached来作为其会话缓存。
总之，没有见过哪个大公司数据量大了，换掉mysql用redis的。
题主你错了，不是用redis代替MySQL，而是引入redis来优化。
BAT里越来越多的项目组已经采用了redis+MySQL的架构来开发平台工具。
如题主所说，当数据多的时候，MySQL的查询效率会大打折扣。我们通常默认如果查询的字段包含索引的话，返回是毫秒级别的。但是在实际工作中，我曾经遇到过一张包含10个字段的表，1800万+条数据，当某种场景下，我们不得不根据一个未加索引的字段进行精确查询的时候，单条sql语句的执行时长有时能够达到2min以上，就更别提如果用like这种模糊查询的话，其效率将会多么低下。
我们最开始是希望能够通过增加索引的方式解决，但是面对千万级别的数据量，我们也不敢贸然加索引，因为一旦数据库hang住，期间的所有数据库写入请求都会被放到等待队列中，如果请求是通过http请求发过来的，很有可能导致服务发生分钟级别的超时不响应。
经过一番调研，最终敲定的解决方案是引入redis作为缓存。redis具有运行效率高，数据查询速度快，支持多种存储类型以及事务等优势，我们把经常读取，而不经常改动的数据放入redis中，服务器读取这类数据的时候时候，直接与redis通信，极大的缓解了MySQL的压力。
然而，我在上面也说了，是redis+MySQL结合的方式，而不是替代。原因就是redis虽然读写很快，但是不适合做数据持久层，主要原因是使用redis做数据落盘是要以效率作为代价的，即每隔制定的时间，redis就要去进行数据备份/落盘，这对于单线程的它来说，势必会因“分心”而影响效率，结果得不偿失。
楼主你好，首先纠正下，数据多并不是一定就用Redis，Redis归属于NoSQL数据库中，其特点拥有高性能读写数据速度，主要解决业务效率瓶颈。下面就详细说下Redis的相比MySQL优点。（ 关于Redis详细了解参见我近期文章： ）
读写异常快
Redis非常快，每秒可执行大约10万次的读写速度。
丰富的数据类型
Redis支持丰富的数据类型，有二进制字符串、列表、集合、排序集和散列等等。这使得Redis很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。
原子性
Redis的所有操作都是原子操作，这确保如果两个客户端并发访问，Redis服务器能接收更新的值。
丰富实用工具 支持异机主从复制
Redis支持主从复制的配置，它可以实现主服务器的完全拷贝。
以上为开发者青睐Redis的主要几个可取之处。但是，请注意实际生产环境中企业都是结合Redis和MySQL的特定进行不同应用场景的取舍。 如缓存——热数据、计数器、消息队列（与ActiveMQ，RocketMQ等工具类似）、位操作（大数据处理）、分布式锁与单线程机制、最新列表（如新闻列表页面最新的新闻列表）以及排行榜等等 可以看见Redis大显身手的场景。可是对于严谨的数据准确度和复杂的关系型应用MySQL等关系型数据库依然不可替。
web应用中一般采用MySQL+Redis的方式，web应用每次先访问Redis，如果没有找到数据，才去访问MySQL。
本质区别
1、mysql：数据放在磁盘 redis：数据放在内存。
首先要知道mysql存储在磁盘里，redis存储在内存里，redis既可以用来做持久存储，也可以做缓存，而目前大多数公司的存储都是mysql + redis，mysql作为主存储，redis作为辅助存储被用作缓存，加快访问读取的速度，提高性能。
使用场景区别
1、mysql支持sql查询，可以实现一些关联的查询以及统计；
2、redis对内存要求比较高，在有限的条件下不能把所有数据都放在redis；
3、mysql偏向于存数据，redis偏向于快速取数据，但redis查询复杂的表关系时不如mysql，所以可以把热门的数据放redis，mysql存基本数据。
mysql的运行机制
mysql作为持久化存储的关系型数据库，相对薄弱的地方在于每次请求访问数据库时，都存在着I/O操作，如果反复频繁的访问数据库。第一：会在反复链接数据库上花费大量时间，从而导致运行效率过慢；第二：反复地访问数据库也会导致数据库的负载过高，那么此时缓存的概念就衍生了出来。
Redis持久化
由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
redis是放在内存的~！
数据量多少绝对不是选择redis和mysql的准则，因为无论是mysql和redis都可以集群扩展，约束它们的只是硬件(即你有没有那么多钱搭建上千个组成的集群)，我个人觉得数据读取的快慢可能是选择的标准之一，另外工作中往往是两者同是使用，因为mysql存储在硬盘，做持久化存储，而redis存储在内存中做缓存提升效率。
关系型数据库是必不可少的，因为只有关系型数据库才能提供给你各种各样的查询方式。如果有一系列的数据会频繁的查询，那么就用redis进行非持久化的存储，以供查询使用，是解决并发性能问题的其中一个手段
即非关系型数据库和关系型数据库。
MySQL的优点：事务处理—保持数据的一致性；由于以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）；可以进行Join等复杂查询
NoSQL的优点：首先它是基于内存的，也就是数据放在内存中，而不是像数据库那样把数据放在磁盘上，而内存的读取速度是磁盘读取速度的几十倍到上百倍，所以NoSQL工具的速度远比数据库读取速度要快得多，满足了高响应的要求。即使NoSQL将数据放在磁盘中，它也是一种半结构化的数据 格式，读取到解析的复杂度远比MySQL要简单，这是因为MySQL存储的是经过结构化、多范式等有复杂规则的数据，还原为内存结构的速度较慢。NoSQL在很大程度上满足了高并发、快速读/和响应的要求，所以它也是Java互联网系统的利器。
简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群;
低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本;
NoSQL的缺点：大多数NoSQL数据库都不支持事务，也不像 SQL Server和Oracle那样能提供各种附加功能，比如BI和报表等; 不提供对SQL的支持
那么该如何选择？
如果规模和性能比24小时的数据一致性更重要，那NoSQL是一个理想的选择 （NoSQL依赖于BASE模型——基本可用、软状态、最终一致性）。
但如果要保证到“始终一致”，尤其是对于机密信息和财务信息，那么MySQL很可能是最优的选择（MySQL依赖于ACID模型——原子性、一致性、独立性和耐久性）。
如果关系数据库在你的应用场景中，完全能够很好的工作，而你又是非常善于使用和维护关系数据库的，那么我觉得你完全没有必要迁移到NoSQL上面，除非你是个喜欢折腾的人。如果你是在金融，电信等以数据为王的关键领域，目前使用的是Oracle数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然也别贸然尝试NoSQL。
然而，在WEB2.0的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分表分库（database sharding）、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果你正在经历这些场合，那么我觉得你应该尝试一下NoSQL了。
具体问题具体分析
MySQL体积小、速度快、成本低、结构稳定、便于查询，可以保证数据的一致性，但缺乏灵活性。
NoSQL高性能、高扩展、高可用，不用局限于固定的结构，减少了时间和空间上的开销，却又很难保证数据一致性。
————————————————
版权声明：本文为CSDN博主「蒟蒻熊」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：
