数据库横向切割: 完美解决海量数据存储问题 (数据库横向切割)

在数字化时代，数据量的飞速增长是一件不争的事实。对于企业来说，如何存储这些数据成为了一项重要的工作。而现有的传统数据库往往无法满足大数据存储的需求。因此，数据库横向切割应运而生。本文将详细介绍数据库横向切割技术，并探讨其应用及优势。

一、数据库横向切割技术概述

数据库横向切割，又称为分表，是将数据库中的数据表按照某个维度进行水平拆分，以实现大数据存储和高并发查询的技术。所谓水平拆分，即将原有的数据表分成若干个子表，每个子表存储一部分数据，各个子表之间没有重叠，每个子表的结构和字段都是一样的。而每个子表存储的数据则依据表名规则进行分配。例如，可以按照时间、地域、产品、用户等维度进行分表，从而实现数据的分布存储。数据库横向切割的技术实现方式主要有两种：一是基于应用程序实现的切割，二是基于数据库本身实现的切割。

二、数据库横向切割技术应用

数据库横向切割技术已经被广泛应用于大型网站、电商、金融、物流等领域。如淘宝，其主要采用基于时间的横向切割方式来存储数据。将每天的数据存储在不同的表中，以便进行快速查询和统计。金融领域也是比较典型的应用场景，银行常常要处理数据量极大的业务数据，如账户信息、交易记录等。而这些数据又需要按照时间、交易类型、客户等维度进行查询和分析。因此，采用数据库横向切割技术来实现高效存储和快速查询成为了不二选择。

三、数据库横向切割技术的优势

1.大数据存储: 数据库横向切割技术可以将大数据拆分为小数据，从而实现数据的分布存储，降低单机的存储压力。同时，减少单一节点的数据量，提高了数据的可用性和可扩展性。

2.高并发查询: 横向切割可以将数据分散至多个节点，同时表结构和表名规则一样，各个节点之间可以独立运行，不会造成压力互相干扰，并能快速查询和统计数据，保证系统的高性能和高可用性。

3.灾备容错: 采用数据库横向切割的方式，即使在某一节点数据出现故障的情况下，其它节点依旧可以正常运行，保证了系统的容错性和可靠性。

四、需要注意的问题

在应用数据库横向切割技术时，需要注意以下几个问题：

1.表结构不能改变: 切割后的各个表结构必须相同，否则可能会影响程序的正常运行。

2.数据一致性: 数据库横向切割后，各个节点的数据必须保持一致。因此，需要采用一些同步机制和备份机制来保证数据的一致性和数据安全。

3.分页查询: 在进行分页查询时，不同表中的数据顺序是不确定的，因此需要对数据进行预处理和排序。

五、结论

数据库横向切割技术是一种有效的解决海量数据存储和高并发查询的方法。通过分布式存储和查询，降低了单一节点的压力，提高了数据的可用性和可扩展性，同时保证了系统的高性能和高可用性。不过，在应用该技术时需要注意数据一致性、分页查询等问题。 在大数据时代，采用数据库横向切割技术，可以让企业更好地应对海量数据的存储和处理需求，实现数据的价值更大化。

相关问题拓展阅读：

• mssql数据库在磁盘阵列运行慢
• 如何对SQL Server数据库进行横向扩展
• mysql数据库表太大查询慢优化的几种方法

mssql数据库在磁盘阵列运行慢

数据库查询速度慢的原因有很多，常见的有以下几种：

1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)

2、I/O吞吐量小，形成了瓶颈效应。

3、没有创建计算列导致查询不优化。

4、内存不足

5、网络速度慢

6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）

7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)

8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。

9、返回了不必要的行和列

10、查询语句不好，没有优化

●可以通过以下方法来优化查询 :

1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2023不在支持。数据量（尺寸）越大，提高I/O越重要。

2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)

3、升级硬件

4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（更好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段。

5、提高网速。

6、扩大服务器的内存,Windows 2023和SQL server 2023能支持4-8G的内存。

配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server?

2023时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5倍。如果另外安装了全文检索功能，并打算运行Microsoft搜索服务以便执行

全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。将SQL Server max server

memory服务器配置选项配置为物理内存的1.5倍（虚拟内存大小设置的一半）。

7、增加服务器CPU个数;但是必须

明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询

的排序、连接、扫描和GROUP BY字句同时执行，SQL

SERVER根据系统的负载情况决定更优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE,INSERT，

DELETE还不能并行处理。

8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like ”a%” 使用索引 like

”%a” 不使用索引用 like ”%a%”

查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。

9、DB Server 和APPLication Server 分离；OLTP和OLAP分离

10、分布式分区视图可用于实现数据库服务器联合体。

联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件”分区视图”）

a、在实现分区视图之前，必须先水平分区表

b、

在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上

运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。

11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。

在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：

1、 查询语句的词法、语法检查

2、 将语句提交给DBMS的查询优化器

3、 优化器做代数优化和存取路径的优化

4、 由预编译模块生成查询规划

5、 然后在合适的时间提交给系统处理执行

6、 最后将执行结果返回给用户。

其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。

12、 Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物.

没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) commit trans 或者将动态SQL

写成函数或者存储过程。

13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。

14、SQL的注释申明对执行没有任何影响

15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。

游标可以按照它所支持的提取选项进行分类：只进必须按照从之一行到最后一行的顺序提取行。FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以在游标中任何地方随机提取任意行。游标的技术在SQL2023下变得功能很强大，他的目的是支持循环。

有四个并发选项 READ_ON：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。

OPTIMISTIC WITH

valueS:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新

某一行。当某个游标以此选项打开时，没有锁控制其中的行，这将有助于更大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获

取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。

选择这个并发选项OPTIMISTIC WITH ROW

VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有

所更改。在SQL Server中，这个性能由timestamp数据类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。

每个数据库都有一个全局当前时间戳值：@@DS。每次以任何方式更改带有 timestamp 列的行时，SQL Server

先在时间戳列中存储当前的 @@DS 值，然后增加 @@DS 的值。如果某 个表具有 timestamp

列，则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需

比较 timestamp 列即可。如果应用程序对没有 timestamp

列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。 SCROLL LOCKS

这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其

上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交或回滚；当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下

一行时，锁就被丢弃。

因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更

新该行。然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的 SELECT

语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器

为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则

COMMIT语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标

SELECT 语句中的锁提示。锁提示 只读乐观数值

*指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。

16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在;用索引优化器优化索引

17、注意UNion和UNion all 的区别。UNION all好

18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的

19、查询时不要返回不需要的行、列

20、 用sp_configure ”query governor cost limit”或者SET

QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。

SET LOCKTIME设置锁的时间

21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行

22、 在SQL2023以前，一般不要用如下的字句: “IS NULL”, “”, “!=”, “!>”,

“!”等还是不能优化，用不到索引。

23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，我们优化的重点是这些慢的地方。

24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引： SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN (‘男’，‘女’)

25、将需要查询的结果预先计算好放在表中，查询的时候再SELECT。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。

26、MIN() 和 MAX()能使用到合适的索引。

27、 数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers,

Constraint（约束如外健主健CheckUNIQUE……,数据类型的更大长度等等都是约束）,Procedure.这样不仅维护工作小，编写程

序质量高，并且执行的速度快。

28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌INsert来插入(不知JAVA

是否)。因为这样应用程序首先将二进制值转换成字符串（尺寸是它的两倍），服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作:

方法：Create procedure p_insert as insert into table(Fimage) values

(@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。

有很多原因啊…系统检查下..数据库配置检查下..网络也有肯能是问题.

如何对SQL Server数据库进行横向扩展

一般人们会选择纵向扩展（scale up）SQL Server数据库，而非横向扩展（scale out）。纵向扩展很容易：增加硬件、处理能力、内存、磁盘和提高网络速度。其原理就是仍然在一台服务器上运行数据库，但是增加了服务器的处理能力和资源。这种方法很昂贵，但是非常简单直接。

　　采用云技术

　　有时候，最简单的方法就是将问题交由其他人处理。微软的Windows Azure云服务包含一个基于云的SQL Server版本SQL Azure.这在技术上并非真正意义的横向扩展，因为它是一种无限纵向扩展方法。所以，转移到Azure并不需要对您的应用程序进行大改动。实际上，您只需要将应用程序迁移到SQL Azure,然后支付存储、处理和数据传输费用。这些都是收费服务，但是您不需要再担心扩展问题。

　　复制

　　SQL Server原生复制是一种支持横向扩展的解决方案，与数据库的创建和使用方式有关。您只需要在多台服务器上复制多个数据库副本，然后将不同的用户指向各台服务器。这种方法通常最适合支持地理位置分散的用户，如亚洲办公室的用户使用服务器1,而北美办公室的用户则使用服务器2.每一台服务器都拥有完整的数据副本，并且会复制伙伴服务器的所有修改。

　　这种方法不支持自动负载均衡，并且最适合用在用户固定只使用一部分数据的情况。换而言之，如果亚洲用户只需要编辑与他们办公室相关的数据–例如，主要是亚洲客户的信息，那么复制能够保证其他数据库副本也包含这些记录的副本。如果所有用户都需要编辑完整的数据集，那么复制就变得有一些复杂，因为SQL Server必须在支持用户的同时，编辑位于不同服务器的同一个数据。

　　SQL Server的合并复制能够处理这种冲突，但是您必须进行一些自定义合并编程，这意味着您的开发人员必须开发一些算法，确定用户并发访问数据时谁获取编辑权限。客户应用程序也需要增加编程；使它们不仅向数据库提交数据修改，也要循环检查这些修改是否被其他并发用户重写。用户也需要重新培训，因为客户端应用程序可能会提示：”您正在编程的数据已经发生变化。您需要重新检查，确定您的编辑是否仍然有效。”

　　联合数据库

　　另一个重要的横向扩展方法是联合。通过这种方法，您可以将数据库划分到多台服务器上。垂直分割将同一个表的不同行保存到不同的服务器上。同时，地理分区是最常用的方法：将所有亚洲数据记录保存在一台服务器上，而所有欧洲数据则保存在另一台服务器上。这种方法不同于整体复制：每一个位置的服务器都不具备完整的数据库，而只拥有该位置的数据。通过实现一种SQL Server分布式分区视图而形成完整的表，用户就可以浏览一个”联合”或组合的数据视图。水平分割则将表的字段保存在不同的服务器上，因此各台服务器一起协作构成组合的表。

　　这些数据库的创建并不简单，其中涉及一种整体操作。您需要掌握关于数据访问和使用的详细信息，才能够实现正确的部署。此外，您还需要一位SQL Server数据库架构师，他应该全面理解这些技术，分析您的业务情况，并且能够正确地创建这些组件。

　　在一些情况中，实现这种横向扩展对客户端应用程序的改动很小。对于本身在设计上大量使用视图和存储过程进行数据访问的应用程序，更是如此。因为这些元素只是是在后台抽象，在客户端上不会发生变化。但是，这些应用程序并不常见；通常，实现横向扩展都需要修改客户端程序，使客户端与后台结构分离。

　　横向扩展并不简单

　　毫无疑问，实现SQL Server横向扩展非常复杂–这也是Azure等云数据库系统流行的原因之一。此外，有一些第三方供应商能够帮助实现横向扩展技术，而不需要完全依赖SQL Server的原生特性。您需要自己下功夫了解这些方法，理解数据访问和使用方法，这样才能够选择更符合您要求的方法。

mysql数据库表太大查询慢优化的几种方法

优化方案：

主从同步+读写分离：

这个表在有设备条件的情况下，读写分离，这样能减少很多压力，而且数据稳定性也能提高

纵渗前槐向分表：

根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表

通常我们按以下原则进行垂直拆分:（先区分这个表中的冷热数据字段）

把不常用的字段单独放在一张表;

把text，blob等大字段拆分出来放在悔坦附表中;

经常组合查询的列放在一张表中;

缺点是：很多逻辑需要重写，带来很大的工作量。

利用表分区：

这个是推荐的一个解决方案，不会带来重写逻辑等，可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。

横向分表：

1000W条数据不少的，会带来一些运维压力，备份的时候，单表备份所需时间会很长，所以可丛友以根据服务器硬件条件进行水平分表，每个表有多少数据为准。

数据库横向切割的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库横向切割,数据库横向切割: 完美解决海量数据存储问题,mssql数据库在磁盘阵列运行慢,如何对SQL Server数据库进行横向扩展,mysql数据库表太大查询慢优化的几种方法的信息别忘了在本站进行查找喔。