虽然近十年来各种存储技术飞速发展，但关系数据库由于其ACID的特性和功能强大的SQL查询，目前还是各种业务系统中关键和核心的存储系统，很多场景下高性能的设计最核心的部分就是关系数据库的设计。
不管是为了满足业务发展的需要，还是为了提升自己的竞争力，关系数据库厂商（Oracle、DB2、MySQL 等）在优化和提升单个数据库服务器的性能方面也做了非常多的技术优化和改进。但业务发展速度和数据增长速度，远远超出数据库厂商的优化速度，尤其是互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。
MySQL的复制功能是其高可用性和可扩展性的基石，它允许数据从一个数据库服务器（主服务器）复制到一个或多个数据库服务器（从服务器）。然而，在实际操作中，复制系统可能会遭遇外键约束带来的挑战。本文旨在深入探讨外键对MySQL复制系统的影响，并提供一些应对策略，以确保数据库的稳定运行和数据的完整性。
sql server 作为目前主流的数据库，用户遍布世界各地。sql server也有一些比较成熟的主备方案，目前主要有：复制模式(发布-订阅模式)、镜像传输模式、日志传输模式、故障转移集群。后面会一一介绍介绍各自的优缺点。
在我们日常的测试工作中，不可避免的要对mysql的性能进行测试，对于大部分测试人员而言，工具的选择可能就是第一道门槛。
像Facebook、开心001、人人网、优酷、豆瓣、淘宝等高流量、高并发的网站，单点数据库很难支撑得住，WEB2.0类型的网站中使用MySQL的居多，要么用MySQL自带的MySQL NDB Cluster(MySQL5.0及以上版本支持MySQL NDB Cluster功能)，或者用MySQL自带的分区功能(MySQL5.1及以上版本支持分区功能)，我所知道的使用这两种方案的很少，一般使用主从复制，再加上MySQL Proxy实现负载均衡、读写分离等功能，在使用主从复制的基础上，再使用垂直切分及水平切分;或者不使用主从复制，完全使用垂直切分加上水平切分再加上类似Memcached的系统也可以解决问题。
如果使用的是 Windows(Windows Mobile 除外)或 Unix 平台，则可以指定一个中央 LDAP 服务器来跟踪企业中的所有数据库服务器。如果数据库服务器在 LDAP 服务器中自行注册，客户端便可以查询 LDAP 服务器，找到其要查找的数据库服务器，无论这些服务器是在
在Oracle中，什么是延迟段创建（Deferred Segment Creation）？
1.只有用Connector/NET 出现这个问题， 用JDBC驱动没有类似问题。 2.多台应用服务器，只有一台报这个错，因此可以排除服务器端的问题。 3.问题非常随机，重启一下服务器/IIS，就能临时解决问题。 4.有一些场景应用服务器CPU并不是很高，也会偶尔抛出这个错来。
利用 CDC，您可以从现有的应用程序和服务中获取最新信息，创建新的事件流或者丰富其他事件流。CDC赋予您实时访问后端数据库的能力。
造成第三条语句执行时间如此长的主要原因就是大量的 OR 语句会导致 SQL 解析非常耗时.
SQL注入可以出现在任何系统或用户接受数据输入的前端应用中，这些应用之后被用于访问数据库服务器。 HTTP定义了很多种客户端可以发送给服务器的操作，但是这里只关注与SQL注入相关的两种方法：GET和POST。
本文通过XXX高速公路收费系统（以下简称收费系统），来论述分布式数据库的设计与实现。收费系统是我公司近年来接的较为大型的项目，管理结构为三层结构：公司级、收费中心级、收费站级，各级之间即可独立的完成自身业务，又有自上而下的管理关系。收费中心、收费站均为三层C/S结构，公司级采取B/S结构。该系统的数据库也按照三层来设计，收费站存放本站的所有流水数据，收费中心存放所有数据，公司本部存放查询用汇总数据，收费站与收费中心使用事务复制来同歩数据，而收费中心与公司本部使用快照复制来同歩数据，并且使用分级的方法来测试收费站、收费中心与公司本部之间的数据同歩。 在本项目的开发过程中，我担任了数据库的设计工作。
之前我们讲过架构设计的一些原则，和架构设计的方法论，今天我们谈谈高性能数据库集群的设计与应用。
数据库防火墙和一般的传统数据库安全设备不同，它部署在应用服务器和数据库服务器之间。业务系统巨大的流量将穿越数据库防火墙，数据库防火墙任何的风吹草动都会影响业务系统的正常运行。数据库防火墙投放市场之前，不管数据库防火墙功能的多寡，都必须解决两个基本问题：性能和可靠性。
SQL*Plus: Release 10.2.0.4.0 - Production on Sun Sep 15 17:06:51 2013 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. ERROR: ORA-01017: invalid username/password; logon denied
开发一个网站的应用程序，当用户规模比较小的时候，使用简单的：一台应用服务器+一台数据库服务器+一台文件服务器，这样的话完全可以解决一部分问题，也可以通过堆硬件的方式来提高网站应用的访问性能，当然，也要考虑成本的问题。
和Oracle DG，MySQL主从一样，SQL Server也支持主从的高可用。进一步提高数据的安全性和业务的高可用。通过将主库上的日志传输到备用实例上，从而达到主备库数据的一致性。
2、从库的IO线程在指定位置读取主库binlog内容存储到本地的中继日志（Relay Log）中
要完成二进制日志的传输过程，MySQL会在从服务器上启动一个工作线程，称为IO线程，这个IO线程会跟主数据库建立一个普通的客户端连接，然后在主服务器上启动一个特殊的二进制转储线程称为binlogdown线程。
对于任何一个企业来说，数据安全的重要性是不言而喻的。我在开篇词中也曾经强调过，凡是涉及到数据的问题，都是损失惨重的大问题。
最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。
让我们设计一个像Instagram这样的照片共享服务，用户可以上传照片与其他用户共享。类似服务：Flickr、Picasa
数据库服务器可以一起工作，这样如果主要的服务器失效则允许一个第二服务器快速接手它的任务（高可用性），或者可以允许多个计算机提供相同的数据（负载均衡）。理想情况下，数据库服务器能够无缝地一起工作。提供静态网页服务的网页服务器可以非常容易地通过把网页请求均衡到多个机器来组合。事实上，只读的数据库服务器也可以相对容易地组合起来。不幸的是，大部分数据库服务器收到的请求是读/写混合的，并且读/写服务器更难于组合。这是因为尽管只读数据只需要在每台服务器上放置一次，但对于任意服务器的一次写动作却必须被传播给所有的服务器，这样才能保证未来对于那些服务器的读请求能返回一致的结果。
让我们设计一个类似Twitter的社交网络服务。该服务的用户将能够发布推文、关注他人以及喜爱的推文。
1.1 高并发，大流量 1.2 海量数据 存储及管理海量数据，需要大量服务器 1.3 高可用: 7 * 24 小时服务 1.4 用户分布广泛，网络环境复杂 1.5 安全环境恶劣 大型网站几乎每天都被黑客攻击 1.6 需求快速变更，发布频繁 1.7 渐进式发展
前言 京东物流极速的购物体验背后隐藏着怎样的秘诀？仓储和配送时效是其中最为关键的一环。京东物流超强仓配体系，特别是在电商行业中独有的仓储系统，在其中起到了决定性的作用。 当前京东的库房已经遍布全国，京东仓储管理系统（简称WMS系统）是最核心的生产系统，涵盖了从入库，复核，打包，出库、库存和报表等等环节。 而作为系统最后端的数据库，不仅仅承担着存储数据的任务，还是系统可用性的最后一道防线，如何保证仓储系统数据库的高性能和高可用，直接决定了库房生产是否能顺畅进行。 在本篇我们将会详细介绍京东物流仓储系统的数据
在MySQL中，主从架构应该是最基础、最常用的一种架构了。后续的读写分离、多活高可用架构等大多都依赖于主从复制。主从复制也是我们学习MySQL过程中必不可少的一部分，关于主从复制的文章有很多，笔者也来凑凑热闹，写写这方面的内容吧，同时分享下自己的经验和方法。
描述：热键被大量客户端访问，导致大量网络流量集中在一台Redis服务器上，服务器宕机。
主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库，主数据库一般是准实时的业务数据库。您看，像在mysql数据库中，支持单项、异步赋值。在赋值过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。此时主服务器会将更新信息写入到一个特定的二进制文件中。并会维护文件的一个索引用来跟踪日志循环。这个日志可以记录并发送到从服务器的更新中去。当一台从服务器连接到主服务器时，从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从哪个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新
前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服
高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。
高并发经常会发生在有大活跃用户量和用户高聚集的业务场景中，如：秒杀活动、定时领取红包等。
我们都知道查询优化器，知道在查询优化器中会经历逻辑查询优化和物理查询优化。需要注意的是，查询优化器只能在已经确定的情况下（SQL 语句、索引设计、缓冲池大小、查询优化器参数等已知的情况）决定最优的查询执行计划
最近有套测试库，出现了很诡异的现象，通过PLSQL Developer登录这套数据库(用户名：user_a)的时候异常的慢，几分钟才能连上，从现象来看，可能有很多原因，大家可以先考虑下可能的原因有什么？
一般我们业务在读多写少的场景下，遇到的第一个瓶颈就是数据库这块，大量的读请求会来到数据库，这样如果你初期部署的一个数据库就会造成IO大量增加，使得请求变慢，甚至会卡死整个数据库，到了这个阶段，我们一般会将读请求和写请求进行分开数据处理，即采用主从读写分离的方式。
MySQL 主从复制（Master-Slave Replication）是一种数据复制技术，用于在多个数据库服务器之间的数据同步。在主从复制架构中，一个服务器被设置为主服务器（Master），充当数据源，其他服务器被设置为从服务器（Slave），用来复制主服务器的数据。
此篇已收录至《大型网站技术架构》读书笔记系列目录贴，点击访问该目录可获取更多内容。
和对外部世界可访问的任何服务器守护进程一样，我们也建议在一个独立的用户账户下运行PostgreSQL。这个用户账户应该只拥有被该服务器管理的数据，并且应该不能被其他守护进程共享（例如，使用用户nobody是一个坏主意）。我们不建议把可执行文件安装为属于这个用户，因为妥协系统可能接着修改它们自己的二进制文件。
如图，假设我们申请了4台数据库服务器，每台上面部署了8个数据库，每个数据库对于每张表分了32张表
服务器层一般是来自多个供应商的硬件和来自多个来源软件的多样化宇宙。通常，解决服务器底层性能问题往往是困难的，或者出于安全原因，很难处理。即使碰巧发现了底层的性能“事件”，传统上测量和分析软硬件性能的工具也较少，而且往往是针对供应商的。因为真正跨平台工具包很少存在，所以没有标准的方法来准确地查看事件、记录事件以供以后分析，或者有效地解决问题。
1.慢查询：很难在短时间内过滤出需要的数据 查询字区分度低 -> 要在大数据量的表中筛选出来其中一部分数据会产生大量的磁盘io -> 降低磁盘效率
原文：https://segmentfault.com/a/1190000019460946
6月6日晚，林志玲与Akira公布婚讯、徐蔡坤祝福高考同学超常发挥，粉丝们百万的转发和点赞造成微博短暂宕机。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
