浅谈MySQL和Access数据库的区别

浅谈MySQL和Access数据库的区别,第1张

MySQL和Access的区别

MySQL特性:很便宜,通常是免费的网络承载少查询优化可以简便的应用程序通过MySQL做备份MySQL *** 纵简单,易上手,且为各种不同的资料格式提供有d性的扩展界面(ODBC)。

Access特性:简单易学,使用方便,开发效率高。

价格:MySQL对于大多数用户而言是免费的,但是如果你以内嵌的方式使用MySQL或者是只使用MySQL的商业用途软件,你才会需要支付一小笔授权费。而Access的价格更贵一些。

并发处理:Access可以处理的连接数目是无限制的,但是连接必须保持在并发处理的范围限制内MySQL内定最大连接数为100个使用者,但是即使网络上有大量的资料往来,也不会对MySQL上的查询优化造成太大影响。

资料更新速度:在 Windows 98 上使用相同的硬件和数据尺寸,处理几十万笔资料的时候,MySQL的资料更新速度将明显快于Access但是如果处理对象结构,Access将会优于MySQL当建立表格(table) 以及索引的时候,MySqL 会将表格锁住,如此一来会导致正在进行的大量资料处理速度慢下来,这会保证用户来访时的查询速度,且不会影响网站开发。

结构的优化:MySQL仅需优化硬件条件,而不是MySQL本身Access的数据库非常的有效率,当然这也有赖于网站的结构设计MySQL不支持外键,优化时注意如何让存取IO减少到最低值、如何让一个或多个 CPU 随时保持在高速作业的状态、以及适当的网络带宽, 而非实际上的设计以及资料查询语句。

数据备份:MySQL Dump 会产生一个比 Access 好很多而且也更可靠的备份档案。相比之下,在 Access中你只是将一个 MDB 档拷贝起来做备份。其次,即使 MySQL 的备份有部分损坏,复原起来也要比一个损坏的 MDB 档要容易得多了。

资料处理能力:MySQL的资料处理能力比Access强eg:MySQL如果处理100MB的档案,不会发生承载过重的迹象,而Access就会造成网站效率低下。

MySQL缺点:没法处理复杂的关联性功能不支持事务处理和事务的提交/撤销MySQL不支持外键以及参考完整性限制,因此MySQL不适用于有复杂资料关系的应用程序,但是Access可以而且MySQL也没有存储进程和触发器。当有许多表格需要同时在一个事务过程中完成更新的时候,MySQL的速度较慢。

mysql分库分表一般有如下场景

其中1,2相对较容易实现,本文重点讲讲水平拆表和水平拆库,以及基于mybatis插件方式实现水平拆分方案落地。

在 《聊一聊扩展字段设计》 一文中有讲解到基于KV水平存储扩展字段方案,这就是非常典型的可以水平分表的场景。主表和kv表是一对N关系,随着主表数据量增长,KV表最大N倍线性增长。

这里我们以分KV表水平拆分为场景

对于kv扩展字段查询,只会根据id + key 或者 id 为条件的方式查询,所以这里我们可以按照id 分片即可

分512张表(实际场景具体分多少表还得根据字段增加的频次而定)

分表后表名为kv_000 ~ kv_511

id % 512 = 1 .... 分到 kv_001,

id % 512 = 2 .... 分到 kv_002

依次类推!

水平分表相对比较容易,后面会讲到基于mybatis插件实现方案

场景:以下我们基于博客文章表分库场景来分析

目标:

表结构如下(节选部分字段):

按照user_id sharding

假如分1024个库,按照user_id % 1024 hash

user_id % 1024 = 1 分到db_001库

user_id % 1024 = 2 分到db_002库

依次类推

目前是2个节点,假如后期达到瓶颈,我们可以增加至4个节点

最多可以增加只1024个节点,性能线性增长

对于水平分表/分库后,非shardingKey查询首先得考虑到

基于mybatis分库分表,一般常用的一种是基于spring AOP方式, 另外一种基于mybatis插件。其实两种方式思路差不多。

为了比较直观解决这个问题,我分别在Executor 和StatementHandler阶段2个拦截器

实现动态数据源获取接口

测试结果如下

由此可知,我们需要在Executor阶段 切换数据源

对于分库:

原始sql:

目标sql:

其中定义了三个注解

@useMaster 是否强制读主

@shardingBy 分片标识

@DB 定义逻辑表名 库名以及分片策略

1)编写entity

Insert

select

以上顺利实现mysql分库,同样的道理实现同时分库分表也很容易实现。

此插件具体实现方案已开源: https://github.com/bytearch/mybatis-sharding

目录如下:

mysql分库分表,首先得找到瓶颈在哪里(IO or CPU),是分库还是分表,分多少?不能为了分库分表而拆分。

原则上是尽量先垂直拆分 后 水平拆分。

以上基于mybatis插件分库分表是一种实现思路,还有很多不完善的地方,

例如:


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/zaji/7093511.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-01
下一篇2023-04-01

发表评论

登录后才能评论

评论列表(0条)

    保存