分库分表数据库有哪些，mysql数据库分库分表哪个工具好我整理出来了五个求点评

来源：整理时间：2024-06-06 15:37:46 编辑：黑码技术手机版

1，mysql数据库分库分表哪个工具好我整理出来了五个求点评

1 用户类库：用于保存了用户的相关信息。例如：db_user,db_system,db_company等。2 业务类库：用于保存主要业务的信息。比如主要业务是笑话，用这个库保存笑话业务。例如：db_joke,db_temp_joke等。3 内存类库：主要用Mysql的内存引擎。前台的数据从内存库中查找，速度快。例如：heap。4 图片类库：主要保存图片的索引以及关联。例如：db_img_index，db_img_res。5 日志类库：记录点击,刷新,登录等日志信息。例如：db_log_click,db_log_fresh,db_log_login。6 统计类库：对业务的统计，比如点击量,刷新量等等。例如db_stat。

支持一下感觉挺不错的

mysql数据库分库分表哪个工具好我整理出来了五个求点评

2，数据库有哪些种类

楼上各位：人家问题好象是问的数据库的种类，即数据库（DB）的类型问题，不是问的数据库管理系统（DBMS）的种类问题。我认为，就目前来讲数据库按其结构来讲，可分为三类：1、层次型2、网状型3、关系型上面，大家回答的都是处理关系型数据库系统。目前大多数集成开发环境（包括语言）都可以用来处理数据库，可以说不胜枚举。就关系型DBMS来说，我认为:中小型的代表有Access、FoxBASE中型的代表有VFP、dBASE、PB大型的代表有oracle、SQL

“逍遥忘我”只说了3个网页用的数据库。既然你不知道，全部罗列出来是没有意义的，数据库太多了，你不说你的工作是涉及哪方面，恐怕很难提供更适合你的数据库。

初级应用一般是ACCESS 配合的脚本程序一般是 ASP ASP.NET JSPMICROSOFT SQL 比较复杂点不过功能强大很多配合的脚本和ACCESS的一样MYSQL和PHP的组合是比较完美的如果你需要处理1000W条数据以上级别的数据,那以上的都不合适,一般用的比较多的是ORACLE 这个入门难度非常大如果想学的话就先学MICROSOFT SQL吧,这个网上教学比较多，而且ASP.NET 2.0问世后,应用的会非常广泛的.

看你要问什么问题了？是现在流行哪些数据库？关系的：mysql、oracle、sqlserver、db2、sqlite（嵌入式开发的）等等。nosql：dynamodb、bigtable、hbase、mongodb、couchdb、nosql，很多，只听过没见过。还是有哪几大类数据库类型？层次、网状、关系，这是以前的分类，我不清楚现在流行的nosql是不是应该分类？

跟据你的工作需要来选择数据库才是明智的如果处理少量的数据，可以用Access大量的数据就必须用大型或超大型数据库，像oracle,interbase等如果你对数据处理要求速度，那么可以选择paradox

数据库有哪些种类

3，mysql怎样分库

你需要怎么分？因为数据表太大影响性能了？建议直接分表数据，性质和mysql分区差不多，例如：把某个范围内的id的记录拷贝至另外的库，这样就实现大表变小表，当然，程序上也需要改动

TiDB 社区（AskTUG）对于传统数据库，无论是水平还是垂直分库，都是很繁琐，耗时耗力的工作，TiDB 作为 NewSQL 数据库，根据自身特性，完美解决该问题水平弹性扩展通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。分布式事务TiDB 100% 支持标准的 ACID 事务。

1 基本思想之什么是分库分表？从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。2 基本思想之为什么要分库分表？数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（cpu、磁盘、内存、io等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。3 分库分表的实施策略。分库分表有垂直切分和水平切分两种。3.1 何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workdb、商品数据库paydb、用户数据库userdb、日志数据库logdb等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。3.2 何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userid散列，进行划分，然后存储到多个结构相同的表，和不同的库上。例如，我们的userdb中的用户数据表中，每一个表的数据量都很大，就可以把userdb切分为结构相同的多个userdb：part0db、part1db等，再将userdb上的用户数据表usertable，切分为很多usertable：usertable0、usertable1等，然后将这些表按照一定的规则存储到多个userdb上。3.3 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。4 分库分表存在的问题。4.1 事务问题。在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。4.2 跨库跨表的join问题。在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。4.3 额外的数据管理负担和数据运算压力。额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表usertable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。上述整理于互联网

mysql怎样分库