• [数据库] MySQL细粒度锁优化特性咨询?
    现网为MySQL 8.0.20,我的myql是已经安装编译好了的,想通过安装MySQL细粒度锁优化特性和MySQL无锁优化特性两个补丁包对mysql进行优化。查看操作手册存在如下问题?麻烦大神帮忙解答下我的myql是已经安装编译好了的,是否只需要下载对应的补丁包,通过步骤3和步骤4合入补丁就行了?还是需要按照步骤5对mysql重新编译安装?如果需要对现有mysql重新安装编译,那是否意味着需要对mysql重新初始化等操作???
  • [技术干货] 8月数据库排行榜:Oracle 大跌,MySQL上涨
    Oracle 较上月减少了 19.50 分,是本月分数下降最多的数据库,并且连续两个月出现了下滑。分数上涨较多的则是 MySQL 和 MongoDB,两者分别增加了 7.98 和 4.68 分。DB-Engines 数据库流行度排行榜发布了 8 月份的更新。可以看到,Oracle 较上月减少了 19.50 分,是本月分数下降最多的数据库,并且连续两个月出现了下滑。分数上涨较多的则是 MySQL 和 MongoDB,两者分别增加了 7.98 和 4.68 分。不过和去年同期相比,三巨头(Oracle、MySQL 和 SQL Server)和 MongoDB 的分数均下降了不少。与之形成对比的 PostgreSQL 则保持着稳定的上升趋势,其每月流行度分数跟去年同期相比都有不少的上涨。下表是 TOP 10 数据库的最新分数和变化情况。继续看看主流数据库的分数趋势变化:最后看看各类型数据库的排名情况。关系数据库前 10 名Key-Value 数据库前 10 名文档数据库前 10 名时序数据库前 10 名图数据库前 10 名DB-Engines 根据流行度对数据库管理系统进行排名,排名每月更新一次。排名的数据依据 5 个不同的指标:Google 以及 Bing 搜索引擎的关键字搜索数量Google Trends 的搜索数量Indeed 网站中的职位搜索量LinkedIn 中提到关键字的个人资料数Stackoverflow 上相关的问题和关注者数量这份榜单分析旨在为数据库相关从业人员提供一个技术方向的参考,其中涉及到的排名情况并非基于产品的技术先进程度或市场占有率等因素。无论排名先后,选择适合与企业业务需求相比配的技术才是最重要的。来源:OSCHINA
  • [问题求助] MySQL 返回 #1054 - Unknown column 'pics' in 'field list'
    【操作步骤&问题现象】在本地pbootcms网站测试中,我想要将Sqlite数据库转mysql数据库。 mysql版本5.7然后报错:  #1054 - Unknown column 'picstitle' in 'field list'【截图信息】
  • [云数据迁移] 几大主流数据库mysql 、SQLserver、oracle的迁移工具和迁移方法
    1、Mysql一、mysqldump步骤:1.使用mysqldump导出自建数据库的数据2.将导出的两个文件上传到ECS实例上3.将导出的文件导入到目标RDS中4.导入成功后登录RDS实例数据库中查看数据是否正常。二、数据复制DRS步骤:(以本地mysql迁移至RDS为例)1.在“实时迁移管理”页面,单击“创建迁移任务”,进入创建迁移任务页面。2.在“迁移实例”页面,填选区域、任务名称、描述、迁移实例信息。3.在“源库及目标库”页面,迁移实例创建成功后,填选源库信息和目标库信息,单击“源库和目标库”处的“测试连接”,分别测试并确定与源库和目标库连通后,勾选协议。4.在“迁移设置”页面,设置迁移用户和迁移对象.5.在“预检查”页面,进行迁移任务预校验,校验是否可进行迁移。6.进入“参数对比”页面,进行参数对比。7.在“任务确认”页面,设置迁移任务的启动时间、任务异常通知设置、SMN主题、时延阈值、任务异常自动结束时间,并确认迁移任务信息无误后,单击“启动任务”,提交迁移任务。2. SQL server 工具1 使用SQLserver导入导出功能将本地SQL Server数据库迁移到RDS for SQL Server二、步骤:(以本地sqlserver迁移至RDS为例)1.登录控制台,选择“数据库 > 云数据库 RDS”“实例管理”页面,选择目标实例,单击实例名称,进入实例的“基本信息”页签。2.在“基本信息”页签下单击“绑定”,在弹出框选择对应的弹性IP。3.在本地安装SQL Server客户端管理工具,通过弹性IP进行连接4.通过SQL Server自带的脚本生成工具,生成ECS上的数据库结构脚本5.在SSMS客户端中打开生成的脚本SQL文件,连接到RDS对应实例上。6.完成以上步骤后通过SQL Server自带的导入导出功能完成数据迁移。工具2 DRS备份迁移步骤 https://support.huaweicloud.com/backupmig-drs/drs_02_0009.html1.在“备份迁移管理”页面,单击“创建迁移任务”。在“选定备份”页面输入任务名称和描述,填选备份文件信息,单击“下一步”。在“选定目标”页面,根据所选数据库类型,配置相应的数据库信息,单击“下一步”在“信息确认”页面核对配置详情后,勾选协议,单击“下一步”。在“备份迁移管理”页面任务列表中,观察对应的恢复任务的状态为“恢复中”,恢复成功后,任务状态显示“成功”。工具3 Golden Gate 在源端和目标端的数据盘建立ggs目录将OGG软件包解压到ggs目录中打开源端和目标的SQL Server代理服务并将启动类型改为自动在源端建立数据库source,目标端建立数据库target在源端和目标端SQLServer中执行对应的语句创建测试表为源端和目标端创建用户,并授权源端:并授权用户名和密码在源端source库启用cdc在源端和目标端分别创建ODBC数据源ogg配置,源端和目标端的ogg安装目录中执行ggsci。 配置完成,测试迁移是否正常使用3、Oracle一、工具1.若采用工具流至云下或云上自建oracle:Oracle Golden Gate/Data guard/Always On/数据库自带迁移工具等2.若采用公有云服务至云数据库postgre:UGO+DRS二、Oracle数据库迁移上云的流程迁移上云流程(以GoldenGate为例)Oracle GoldenGate 数据复制过程如下:利用抽取进程(Extract Process)在源端数据库中读取Online Redo Log或者Archive Log,然后进行解析,只提取其中数据的变化信息,比如DML操作——增、删、改操作将抽取的信息转换为GoldenGate自定义的中间格式存放在队列文件(trail file)中再利用传输进程将队列文件(trail file)通过TCP/IP传送到目标系统。目标端有一个进程叫Server Collector,这个进程接受了从源端传输过来的数据变化信息把信息缓存到GoldenGate 队列文件(trail file)当中,等待目标端的复制进程读取数据。• GoldenGate 复制进程(replicat process)从队列文件(trail file)中读取数据变化信息,并创建对应的SQL语句,通过数据库的本地接口执行,提交到目标端数据库,提交成功后更新自己的检查点,记录已经完成复制的位置,数据的复制过程最终完成
  • [技术干货] mysql5.7 性能优化配置 innodb_buffer_pool_size[转载]
    一、缓冲池​​​​​14.5.1 Buffer Pool缓冲池是主内存中的一个区域,InnoDB在访问表和索引数据时将其缓存。缓冲池允许直接从内存访问经常使用的数据,从而加快处理速度。在专用服务器上,高达80%的物理内存通常分配给缓冲池。为了提高大容量读取操作的效率,缓冲池被划分为可能容纳多行的页面。为了提高缓存管理的效率,缓冲池被实现为页面的链接列表;很少使用的数据会使用最不常用(LRU)算法的变体从缓存中过时。了解如何利用缓冲池将频繁访问的数据保存在内存中是MySQL调优的一个重要方面。二、innodb_buffer_pool_size14.8.3.1 Configuring InnoDB Buffer Pool Sizeinnodb_buffer_pool_size=innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances. innodb_buffer_pool_size默认是128M,缓冲池的大小(字节),InnoDB缓存表和索引数据的内存区域。默认值为134217728字节(128MB)。最大值取决于CPU架构;32位系统的最大值为4294967295(2**32-1),64位系统的最大值为18446744073709551615(2**64-1)。在32位系统上,CPU体系结构和操作系统的实际最大大小可能低于规定的最大大小。当缓冲池的大小大于1GB时,将innodb_buffer_pool_instances设置为大于1的值可以提高繁忙服务器上的可伸缩性。更大的缓冲池需要更少的磁盘I/O来多次访问相同的表数据。在专用数据库服务器上,可以将缓冲池大小设置为机器物理内存大小的80%。在配置缓冲池大小时,请注意以下潜在问题,并准备在必要时缩小缓冲池的大小。对物理内存的竞争可能会导致操作系统中的分页。InnoDB为缓冲区和控制结构保留额外的内存,因此总分配空间比指定的缓冲池大小大约大10%。缓冲池的地址空间必须是连续的,这在具有在特定地址加载DLL的Windows系统上可能是一个问题。初始化缓冲池的时间大致与其大小成正比。在具有大型缓冲池的实例上,初始化时间可能很长。要缩短初始化周期,可以在服务器关闭时保存缓冲池状态,并在服务器启动时恢复。参见第14.8.3.6节“保存和恢复缓冲池状态”。当增加或减少缓冲池大小时,该操作将分块执行。区块大小由innodb_buffer_pool_chunk_size变量定义,该变量的默认值为128 MB。缓冲池大小必须始终等于或是innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍数。如果将缓冲池大小更改为不等于innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的值或其倍数,缓冲池大小将自动调整为等于或其倍数的值。innodb_buffer_pool_size可以动态设置,这允许您在不重新启动服务器的情况下调整缓冲池的大小。Innodb_buffer_pool_resize_status变量报告在线缓冲池大小调整操作的状态。有关更多信息,请参阅第14.8.3.1节“配置InnoDB缓冲池大小”。innodb_buffer_pool_chunk_size 默认是128Minnodb_buffer_pool_instances默认是8(如果innodb_buffer_pool_size < 1GB,则是1)14.8.3.2 Configuring Multiple Buffer Pool Instances2.1查看现有配置mysql> show variables like 'innodb_buffer_pool%';+-------------------------------------+----------------+| Variable_name                       | Value          |+-------------------------------------+----------------+| innodb_buffer_pool_chunk_size       | 134217728      || innodb_buffer_pool_dump_at_shutdown | ON             || innodb_buffer_pool_dump_now         | OFF            || innodb_buffer_pool_dump_pct         | 25             || innodb_buffer_pool_filename         | ib_buffer_pool || innodb_buffer_pool_instances        | 1              || innodb_buffer_pool_load_abort       | OFF            || innodb_buffer_pool_load_at_startup  | ON             || innodb_buffer_pool_load_now         | OFF            || innodb_buffer_pool_size             | 134217728      |+-------------------------------------+----------------+2.2简单优化把innodb_buffer_pool_size设置为1G。个人建议innodb_buffer_pool_size设置为系统内存的50%。最好设置为:innodb_buffer_pool_size=innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances.否则,innodb_buffer_pool_size自动调整可能是innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的两倍。my.cnf# innodb缓冲池大小innodb_buffer_pool_size=1G # innodb缓冲池块大小innodb_buffer_pool_chunk_size=128M # innodb缓冲池实例数innodb_buffer_pool_instances=8重启数据库调整后:mysql> show variables like 'innodb_buffer_pool%';+-------------------------------------+----------------+| Variable_name                       | Value          |+-------------------------------------+----------------+| innodb_buffer_pool_chunk_size       | 134217728      || innodb_buffer_pool_dump_at_shutdown | ON             || innodb_buffer_pool_dump_now         | OFF            || innodb_buffer_pool_dump_pct         | 25             || innodb_buffer_pool_filename         | ib_buffer_pool || innodb_buffer_pool_instances        | 8              || innodb_buffer_pool_load_abort       | OFF            || innodb_buffer_pool_load_at_startup  | ON             || innodb_buffer_pool_load_now         | OFF            || innodb_buffer_pool_size             | 1073741824     |+-------------------------------------+----------------+这些参数也支持在线调整,可考虑在业务低峰时调整。Configuring InnoDB Buffer Pool Size Online2.3配置是否合适5.1.3 Server Option, System Variable, and Status Variable Reference2.3.1查询缓存命中率:mysql> show status like 'Innodb_buffer_pool_read%';+---------------------------------------+--------------+| Variable_name                         | Value        |+---------------------------------------+--------------+| Innodb_buffer_pool_read_ahead_rnd     | 0            || Innodb_buffer_pool_read_ahead         | 20294922     || Innodb_buffer_pool_read_ahead_evicted | 1240192      || Innodb_buffer_pool_read_requests      | 299216558100 || Innodb_buffer_pool_reads              | 1167281260   |+---------------------------------------+--------------+Innodb_buffer_pool_read_requests:逻辑读取请求的数量。Innodb_buffer_pool_reads:InnoDB无法从缓冲池满足的逻辑读取数,必须直接从磁盘读取。percent = innodb_buffer_pool_read_requests / (innodb_buffer_pool_reads + innodb_buffer_pool_read_requests) * 100%上述的 percent>=99%,则表示当前的buffer pool满足当前的需求。否则需要考虑增加 innodb_buffer_pool_size的值。2.3.2缓存数据页占比:mysql> show status like 'Innodb_buffer_pool_pages%';+----------------------------------+----------+| Variable_name                    | Value    |+----------------------------------+----------+| Innodb_buffer_pool_pages_data    | 7003     || Innodb_buffer_pool_pages_dirty   | 0        || Innodb_buffer_pool_pages_flushed | 19906085 || Innodb_buffer_pool_pages_free    | 1021     || Innodb_buffer_pool_pages_misc    | 167      || Innodb_buffer_pool_pages_total   | 8191     |+----------------------------------+----------+innodb_buffer_pool_pages_data:InnoDB缓冲池中包含数据的页数。这个数字包括脏页和干净页。(使用压缩表时,报告的Innodb_buffer_pool_pages_数据值可能大于)percent = Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total * 100%上述的 percent>=95% 则表示当前的innodb_buffer_pool_size满足当前的需求。否则可以考虑增加 innodb_buffer_pool_size的值。2.4如何判断MySQL使用内存会不会过高可能还有有一些担心,所有参数设置完毕后MySQL的占用会过高导致内存溢出,那么我们可以算一下他会不会太高。通过下面的SQL语句:SELECT ((@@key_buffer_size+@@innodb_buffer_pool_size+@@innodb_log_buffer_size)/1024/1024)+((@@read_rnd_buffer_size+@@read_buffer_size+@@myisam_sort_buffer_size+@@sort_buffer_size+@@join_buffer_size)/1024/1024*@@max_connections);最终单位为MB若该值不超过系统可用内存,说明还好(理论)2.5其他命令mysql> show status like 'Innodb_buffer_pool%';+---------------------------------------+--------------------------------------------------+| Variable_name                         | Value                                            |+---------------------------------------+--------------------------------------------------+| Innodb_buffer_pool_dump_status        | Dumping of buffer pool not started               || Innodb_buffer_pool_load_status        | Buffer pool(s) load completed at 220313  7:31:02 || Innodb_buffer_pool_resize_status      |                                                  || Innodb_buffer_pool_pages_data         | 6999                                             || Innodb_buffer_pool_bytes_data         | 114671616                                        || Innodb_buffer_pool_pages_dirty        | 0                                                || Innodb_buffer_pool_bytes_dirty        | 0                                                || Innodb_buffer_pool_pages_flushed      | 19905034                                         || Innodb_buffer_pool_pages_free         | 1024                                             || Innodb_buffer_pool_pages_misc         | 168                                              || Innodb_buffer_pool_pages_total        | 8191                                             || Innodb_buffer_pool_read_ahead_rnd     | 0                                                || Innodb_buffer_pool_read_ahead         | 20294410                                         || Innodb_buffer_pool_read_ahead_evicted | 1240164                                          || Innodb_buffer_pool_read_requests      | 299111990637                                     || Innodb_buffer_pool_reads              | 1167212424                                       || Innodb_buffer_pool_wait_free          | 1193110                                          || Innodb_buffer_pool_write_requests     | 156029072                                        |+---------------------------------------+--------------------------------------------------+mysql> show engine innodb status \Gmysql> SHOW GLOBAL STATUS \G 太多了。三、其他待优化:join_buffer_size = 128Msort_buffer_size = 2Mread_rnd_buffer_size = 2Mmysql> show variables like '%buffer_size%';+-------------------------+----------+| Variable_name           | Value    |+-------------------------+----------+| bulk_insert_buffer_size | 8388608  || innodb_log_buffer_size  | 16777216 || innodb_sort_buffer_size | 1048576  || join_buffer_size        | 262144   || key_buffer_size         | 8388608  || myisam_sort_buffer_size | 8388608  || preload_buffer_size     | 32768    || read_buffer_size        | 131072   || read_rnd_buffer_size    | 262144   || sort_buffer_size        | 262144   |+-------------------------+----------+四、参考:Mysql优化之innodb_buffer_pool_size篇MySQL参数 之 innodb_buffer_pool_sizeMySQL中innodb_buffer_pool_size的配置MySQL基准测试innodb_buffer_pool_size对性能影响五、文档:Chapter 8 Optimization8.1 Optimization Overview8.2 Optimizing SQL Statements8.3 Optimization and Indexes8.4 Optimizing Database Structure8.5 Optimizing for InnoDB Tables8.6 Optimizing for MyISAM Tables8.7 Optimizing for MEMORY Tables8.8 Understanding the Query Execution Plan8.9 Controlling the Query Optimizer8.10 Buffering and Caching8.11 Optimizing Locking Operations8.12 Optimizing the MySQL Server        8.12.4.1 How MySQL Uses Memory8.13 Measuring Performance (Benchmarking)8.14 Examining Server Thread (Process) Information8.5 Optimizing for InnoDB Tables8.5.1 Optimizing Storage Layout for InnoDB Tables8.5.2 Optimizing InnoDB Transaction Management8.5.3 Optimizing InnoDB Read-Only Transactions8.5.4 Optimizing InnoDB Redo Logging8.5.5 Bulk Data Loading for InnoDB Tables8.5.6 Optimizing InnoDB Queries8.5.7 Optimizing InnoDB DDL Operations8.5.8 Optimizing InnoDB Disk I/O8.5.9 Optimizing InnoDB Configuration Variables8.5.10 Optimizing InnoDB for Systems with Many Tables14.8.3 InnoDB Buffer Pool Configuration14.8.3.1 Configuring InnoDB Buffer Pool Size14.8.3.2 Configuring Multiple Buffer Pool Instances14.8.3.3 Making the Buffer Pool Scan Resistant14.8.3.4 Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)14.8.3.5 Configuring Buffer Pool Flushing14.8.3.6 Saving and Restoring the Buffer Pool State————————————————版权声明:本文为CSDN博主「躁动的青年」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。原文链接:https://blog.csdn.net/haveqing/article/details/124788083
  • [技术干货] 新数据库时代,不要只学 Oracle、MySQL
    目前,中国已经进入“人人都是开发者,家家都是数据公司”的新数据库时代。今日,CSDN 创始人&董事长、极客帮创投创始合伙人蒋涛发表了《新数据库时代》主题演讲分享。他指出,在开源吞噬世界的背景下,数据库也在大力拥抱开源。不同于传统关系型数据库,新型数据库已成为行业风口,急需大量相关人才汇入,青年才俊应当抓住机遇,迎接挑战。以下是蒋涛演讲实录:大家好,我是CSDN创始人蒋涛。我是程序员出身,30年前数据库就是程序员的必备技能,而近几年,数据库又有了很大的发展。作为投资人,我也曾投资过巨杉数据库。CSDN目前是中国知名的技术社区,据最新数据显示,CSDN的用户量已经超过3,600万,公司规模也在不断发展壮大。如今,开发者变得越来越重要,我们围绕着开发者建立了一系列业务支持体系,帮助开发者获得能力与成长。其中,不仅有协助开发的工具开发云(https://dev.csdn.net),还有帮助大家找到更好职业的人才云等。目前,开发者市场越来越好,相信“人人都是开发者,家家都是技术公司”的时代不久后就要到来。在此背景下,中国想要构建自己的核心技术生态,数据库是其中关键。今天我将围绕三个部分分享《新数据库时代》:第一是揭示「我们正在进入的数据大时代」现状;第二是了解「开源正在吞噬数据库」的改变;第三是把握「新型的数据库人才特别抢手」的趋势。1、数据大时代我们正处于大数据时代,几乎每家公司都在对自己的业务进行数字化变革。据统计,全球数据量每年持续增加,去年全球产生的数据总量是79ZB,2025年预计将达到180ZB。由于云技术的发展,越来越多的数据都存储在云端。数据显示,在2016年只有10%的数据储存在云端的数据仓库里,但到了2022年,这个数字已经快速增长到了75%,这说明随着数字经济的发展,每家公司都将成为数据公司,数据库市场也迎来了爆炸性增长。数据库市场历史其实非常悠久,从1964年,世界上第一个数据库系统IDS(Integrated Data Storage,集成数据存储)诞生开始,到今天数据库发展已经快60年。1980年代,数据库开始在中国生根发芽。直到现在,整个全球市场依然保持了20%以上的增长规模。尽管数据库是个古老的技术,但其中又蕴含了很多新的机会。从数据库技术公司融资情况来看,数字非常惊人。过去10年,数据库公司融资总额87亿,其中一半是在过去两年内完成的。2021年,超级独角兽大数据公司Databricks两轮融资总额为26亿美元。如此看来,数据库技术也进入到了一个新时代。2、开源吞噬数据库那么数据库的技术进入到新时代的标志是什么?即“开源吞噬数据库”。开源已经成为所有开发者的必选项,据GitHub统计数据:2016年仅有80万人第一次做出开源代码贡献,而2021年,这个数字已经增长到300万。在数据库领域中,开源的“吞噬”情况也十分明显。dbdb.io(卡内基梅隆大学维护的全球数据库信息库)分析了全球知名的841个数据库系统,其中开源数据库有608个,占比72%,只有200多家是商业数据库。在全球顶尖数据库排行榜中,开源数据库也占到一半。在CSDN制作的2021 数据库全景图(V1.0)中,我们将不同领域的数据库按照开源和闭源两类进行颜色区分,右侧浅绿色的部分是开源数据库,左侧深绿色的部分是闭源数据库。可以很明显地看到开源在快速发展,且有吞噬闭源数据库的趋势。中国数据库在发展核心技术生态的大背景下,也发展得非常的迅猛。dbdb.io(卡内基梅隆大学维护的全球数据库信息库)统计的全球800多家数据库企业中,中国有56家,但实际上中国数据库厂商有200多家。尤其在新型数据库上,中国企业“冒头”较多,例如现在发展势头强劲的TiDB,在GitHub上非常活跃。当然,开发者目前使用较多的还是相对传统的基础关系型数据库MySQL,还有大数据领域Redis、Apache/Hive、MongoDB等相对比较传统的技术,但绝大部分都是开源的。尽管最普遍被使用的依然是关系型数据库,但新型数据库则代表了未来趋势。根据CSDN 2021-2022年数据库开发者大调查显示,在云趋势下,有52%的公司已经部署了云数据库,只有23%的公司尚未计划部署云数据库。新型数据库人才抢手对于目前的就业环境,我认为开发者应当好好学习数据库技术,并且不要局限于仅学习关系型数据库,更要学新型数据库。为什么呢?新型数据库的技术栈跟过去大有不同,关系型数据库只是里面最基础的一环,而数据分析、数据仓库、可视化等很多新型技术栈在涌现。开源中比较热门的新数据库类型包括分布式数据库、时序数据库、图数据库、流式数据库等都在GitHub上排名非常靠前,Star数也非常高。20年前,市面上只有关系型数据库,主要面向事务性的交易。而如今得益于云、微服务、分布式应用、全球规模、实时数据、深度学习等,新的数据库架构应运而生,以解决新的性能需求:快速读取和快速写入的不同系统;专门用于支持实时分析的系统;用于非结构化、半结构化、事务性、关系、图形或时间序列数据的系统;适用于缓存、搜索、基于索引、事件等的数据……据统计,一家企业平均在七个或更多不同的数据库中存储数据。这些新技术带来了新机会,同时也加大了市场对人才的需求。我国数据工程师真正诞生是在十几年前。而现在,随着数据量的激增且更多地存储在云端,越来越多公司变成数据公司、市场对数据公司的需求也在持续增长。基于数据做分析的数据分析工程师也非常重要,他们既要了解数据库的技术,又要懂业务,才能更好地进行数据分析,这样的人才在未来会非常紧俏。据Glassdoor(美国一家做企业点评与职位搜索的职场社区)统计,从2016年到2020年,“数据科学家”在美国最佳工作排行榜中一直位居榜首,被称为21世纪最性感的工作。现在,数据科学家和数据工程师的需求还在持续上升,薪资也是。目前,中国对数据库人才的需求也具有相同趋势,尽管过去在关系型数据库领域处于引领地位的还是Oracle的MySQL数据库。但我相信,中国未来会构建自己的数据库新生态。中国也非常有机会在新技术上进行弯道超车,例如腾讯云数据库TDSQL,以及其他新型数据库。同时,也希望更多CSDN平台上的开发者能够加入新型数据库赛道中来,并欢迎大家去参加能力认证活动。
  • [技术干货] 1267 - Illegal mix of collations (utf8_croatian_ci,IMPLICIT) and
    1267 - Illegal mix of collations (utf8_croatian_ci,IMPLICIT) and (utf8_general_ci,IMPLICIT) for operation '='操作为'='时,排序规则的非法,Mysql排序规则类型不匹配,不能使用等号关联。将utf8_croatian_ci排序规则改成utf8_general_ci即可。每个字符串文字都有一个字符集和一个排序规则。 对于 simple statement ,字符串具有由 和系统变量 定义的连接默认字符集和排序规则。utf8_croatian_ciutf8_croatian_ci规则的"croatian"表示克罗地亚语,则该比较规则是以克罗地亚语的规则进行比较。utf8_general_ciA nonbinary string with utf8 character set and its default collation (that is, utf8_general_ci):SELECT _utf8'Müller';utf8_croatian_ci规则的"croatian"表示克罗地亚语,则该比较规则是以克罗地亚语的规则进行比较。 这里名称utf8_general_ci中的"general"表示其是一种通用的规则。 而名称中的"ci"后缀则意为该比较规则不区分大小写。可通过下面命令查看MySQL中支持的字符集show CHARSET show CHARACTER SET更多内容可以参考mysql官方文档https://docs.oracle.com/cd/E17952_01/index.html
  • [技术干货] Mysql主从复制配置
    原因需要在两个数据库中,进行数据同步。1、基础设置准备#操作系统: centos6.5 #mysql版本: 5.7 #两台虚拟机: node1:192.168.85.11(主) node2:192.168.85.12(从)2、安装mysql数据库#详细安装和卸载的步骤参考对应的文档3、在两台数据库中分别创建数据库--注意两台必须全部执行 create database msb;4、在主(node1)服务器进行如下配置:#修改配置文件,执行以下命令打开mysql配置文件 vi /etc/my.cnf #在mysqld模块中添加如下配置信息 log-bin=master-bin #二进制文件名称 binlog-format=ROW #二进制日志格式,有row、statement、mixed三种格式,row指的是把改变的内容复制过去,而不是把命令在从服务器上执行一遍,statement指的是在主服务器上执行的SQL语句,在从服务器上执行同样的语句。MySQL默认采用基于语句的复制,效率比较高。mixed指的是默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。 server-id=1 #要求各个服务器的id必须不一样 binlog-do-db=msb #同步的数据库名称5、配置从服务器登录主服务器的账号授权--授权操作 set global validate_password_policy=0; set global validate_password_length=1; grant replication slave on *.* to 'root'@'%' identified by '123456'; --刷新权限 flush privileges;6、从服务器的配置#修改配置文件,执行以下命令打开mysql配置文件 vi /etc/my.cnf #在mysqld模块中添加如下配置信息 log-bin=master-bin #二进制文件的名称 binlog-format=ROW #二进制文件的格式 server-id=2 #服务器的id7、重启主服务器的mysqld服务#重启mysql服务 service mysqld restart #登录mysql数据库 mysql -uroot -p #查看master的状态 show master status;8、重启从服务器并进行相关配置#重启mysql服务 service mysqld restart #登录mysql mysql -uroot -p #连接主服务器 change master to master_host='192.168.150.11',master_user='root',master_password='123456',master_port=3306,master_log_file='master-bin.000001',master_log_pos=334; #启动slave start slave #查看slave的状态 show slave status\G(注意没有分号)出现两个YES,证明配置成功。9、此时可以在主服务器进行相关的数据添加删除工作,在从服务器看相关的状态结论在同步过程中出现了问题:从表中已经存在主表已经存在的表主表中删除的表,从表不存在主和有相同的表但是列名不一致数据库结构必须保持一致:从表的字段类型必须与主表保持一直从表的字段顺序必须与主表保持一直,从表可以在顺序一致的情况下新增,字段。依旧可以同步成功 
  • [新手课堂] MySQL,MVCC详解,快照读在RC、RR下的区别
    一、什么是MVCC我们在操作数据库的时候总是这四大类 读读 读写 写读 写写,读读肯定是没有任务数据问题的,但对事物有了解的同学就会知道,读写、写写操作很容易就会导致数据不一致。在此之前解决这类问题的常用方式就是加锁,听名字就知道这是个很复杂、很耗性能的操作,所以大神们不满足这个操作,从而在MySQL里面实现了MVCC。MVCC并不是MySQL独有的,它是一个理念,百度百科解释如下Multi-Version Concurrency Control 多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。MVCC里面有一些关键词,理解这些关键词,你就明白了什么是MVCC。MVCC是解决读写、写读导致数据不一致的问题,写写问题还是需要加锁来解决。所以我们可以使用 MVCC + 锁(乐观锁/悲观锁)来解决全部的问题。二、当前读、快照读当前读就是读取最新的数据,为了保证读取的是最新且准确的数据,所以它在读取的时候会加锁,防止其它事物操作。快照读是不加锁的方式,当一个事物要操作数据库的时候,会在这个事物的基础上形成一个快照,其它的操作就读取这个快照。MVCC就是基于快照读来实现的,在MySQL里面的快照读是基于这样几个关键点来实现的• 三个隐藏参数 (DB_ROW_ID 隐藏主键id、DB_ROLL_PTR 回滚指针、DB_TRX_ID 事物id)• undo log 日志• read view三、隐藏字段假如我们有一张表,里面有两个字段,name、age,但实际上我们表里的数据是这样的3-1、隐藏主键6byte,隐含的自增ID(隐藏主键),如果数据表没有主键,InnoDB会自动以DB_ROW_ID产生一个聚簇索引聚簇索引:数据存储和索引是存在一起的,逻辑上和物理上都是一起的,一个表只能有一个聚簇索引。注:理解聚簇索引可以很好的理解MySQL的索引规则,感兴趣的可以看看这个 MySQL索引详解 3-2、事物id记录这条记录最后一次操作的事物id3-3、回滚指针回滚指针,指向这条记录的上一个版本(存储于rollback segment里),用于配合下面的 undo log。四、undo logundo log 日志分为两种• insert undo log 数据库在插入数据的时候产生,只有在当前事物回滚的时候才有用,所以在当前事物结束的时候它就没用了,就会被删除。• update undo log 数据库在更新、删除的时候产生,除了当前事物会使用,在快照读的时候也会使用,所以不能随便删除,只有在快速读或事务回滚不涉及该日志时,对应的日志才会被purge线程统一清除假设我们的隐藏主键是从1、2、3…, 事物主键、回滚指针也是这样生成的 (事实上不是这样的规则),那么我们对上面的表进行操作,将会形成如下的链式结构。插入数据修改张三为李四修改年纪为25注:这里的指针是指向这条数据,而不是里面的 主键。五、Read View什么是读视图呢?数据库的操作都是多个事物同时进行的,有读有写。假如当前有两个事物,A事物读取,B事物正在更新数据。在A事物开始的时候,就形成当前数据库的一个快照,记录并维护系统当前活跃事务的ID。read view 主要是用来做可见性判断的,它会判断每条记录的的数据,这条数据可能是真实的数据,也可能是undo log 中的数据。read view 用一个可见性的算法,来判断当前是读取真实的数据,还是undo log的数据。这里可以简单理解read view 内部维护了一个事物id列表,里面有最大值和最小值,可以判断其它事物的id是否在这个可见范围内。N、其它N-1、快照读在RC和RR下的区别• RC (read-committed)读已提交, 可能会导致 不可重复读、幻读• RR (repeatable-read)可重复读,可能会导致 不可重复读幻读 : 事物A查询数据库查询出来了20条数据,然后事物B删除了2条数据,这时候事物A再去查询发现只有18条了,从而产生了幻觉。我们知道在RR级别下面不会产生幻读,之所以不会产生幻读,是快照读在RC和RR下的生成的策略不一样。RC隔离级别下,是每个快照读都会生成并获取最新的Read View;而在RR隔离级别下,则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。
  • [技术干货] Python 读取千万级数据自动写入 MySQL 数据库【转载】
    目录前言场景一:数据不需要频繁的写入mysql场景二:数据是增量的,需要自动化并频繁写入mysql总结前言Python 读取数据自动写入 MySQL 数据库,这个需求在工作中是非常普遍的,主要涉及到 python 操作数据库,读写更新等,数据库可能是 mongodb、 es,他们的处理思路都是相似的,只需要将操作数据库的语法更换即可。本篇文章会给大家系统的分享千万级数据如何写入到 mysql,分为两个场景,两种方式。场景一:数据不需要频繁的写入mysql使用 navicat 工具的导入向导功能。支持多种文件格式,可以根据文件的字段自动建表,也可以在已有表中插入数据,非常快捷方便。场景二:数据是增量的,需要自动化并频繁写入mysql测试数据:csv 格式 ,大约 1200万行123import pandas as pddata = pd.read_csv('./tianchi_mobile_recommend_train_user.csv')data.shape打印结果:方式一:python ➕ pymysql 库安装 pymysql 命令:1pip install pymysql代码实现:12345678910111213141516171819202122232425262728293031import pymysql# 数据库连接信息conn = pymysql.connect(       host='127.0.0.1',       user='root',       passwd='wangyuqing',       db='test01',       port = 3306,       charset="utf8")# 分块处理big_size = 100000# 分块遍历写入到 mysqlwith pd.read_csv('./tianchi_mobile_recommend_train_user.csv',chunksize=big_size) as reader:    for df in reader:        datas = []        print('处理:',len(df))#         print(df)        for i ,j in df.iterrows():            data = (j['user_id'],j['item_id'],j['behavior_type'],                    j['item_category'],j['time'])            datas.append(data)        _values = ",".join(['%s', ] * 5)        sql = """insert into users(user_id,item_id,behavior_type        ,item_category,time) values(%s)""" % _values        cursor = conn.cursor()        cursor.executemany(sql,datas)        conn.commit() # 关闭服务conn.close()cursor.close()print('存入成功!')方式二:pandas ➕ sqlalchemy:pandas需要引入sqlalchemy来支持sql,在sqlalchemy的支持下,它可以实现所有常见数据库类型的查询、更新等操作。代码实现:12345from sqlalchemy import create_engineengine = create_engine('mysql+pymysql://root:wangyuqing@localhost:3306/test01')data = pd.read_csv('./tianchi_mobile_recommend_train_user.csv')data.to_sql('user02',engine,chunksize=100000,index=None)print('存入成功!')总结pymysql 方法用时12分47秒,耗时还是比较长的,代码量大,而 pandas 仅需五行代码就实现了这个需求,只用了4分钟左右。最后补充下,方式一需要提前建表,方式二则不需要。所以推荐大家使用第二种方式,既方便又效率高。如果还觉得速度慢的小伙伴,可以考虑加入多进程、多线程。
  • [分享交流] Pisa-Proxy中,为何选用 Rust 来实现 MySQL 代理?
    1.安全性:首先作为数据库治理的核心组件,其语言的安全性是居首位的。Rust 中,类型安全实现内存安全,如所有权机制、借用、生命周期等特性避免了程序开发过程中的空指针、悬垂指针等问题,从而保证了服务在语言层面的安全性。2.优秀的性能表现:Rust 的目标在性能方面对标 C 语言,但在安全和生产力方面则比 C 更胜一筹。其无 GC,不需要开发人员手动分配内存等特性,极大程度地减少内存碎片,简化内存管理。3.低开销:从开发效率和可读可维护性上来说,有足够的抽象能力,并且这种抽象没有运行时开销(runtime cost)。零开销抽象,通过泛型和 Trait 在编译期展开并完成抽象解释。4.实用性:有优秀的包管理器工具 Crate、文档注释支持、详细的编译器提示、友好的错误处理等,在开发过程中能够高效帮助程序员快速开发出可靠、高性能的应用。
  • [技术干货] GaussDB(for MySQL)荣获“云原生技术创新领航者-云原生技术创新案例”大奖
    近日,由中国信息通信研究院主办的“原生聚力,云数赋能”第四届云原生产业大会顺利召开。在这场云原生领域盛会中,华为云GaussDB(for MySQL)云原生数据库凭优越的技术创新实力和实践经验,荣获“云原生技术创新领航者-云原生技术创新案例”大奖。华为云数据库副部长庄乾锋代表GaussDB亮相大会,就大会对GaussDB的认可表示感谢。庄乾锋表示,当前,数据库行业迎来云原生2.0时代,企业对云数据库提出了更高性能、安全可靠、极致扩展等诸多诉求。华为云GaussDB通过整合多年数据库领域经验和客户诉求,构筑云原生数据库全栈能力,构建以应用为中心的新型数据库云服务,积极引领云原生数据库发展新方向。聚焦技术创新 深入云原生领域持续发力作为华为自研的新一代企业级高性能云原生分布式数据库,GaussDB(for MySQL)基于DFV分布式存储,采用存算分离架构,拥有128TB的海量存储空间,可实现超百万级QPS 吞吐,既拥有商业数据库的性能和可靠性,又具备开源数据库的灵活性,在云原生业务场景有非常明显的核心优势。华为独特优势:垂直集成 与传统的线下数据库不同,云数据库有垂直集成云栈中所有层的能力,在云上,存储和数据库的集成能发挥更大的作用。华为作为在云栈各层领先的提供商,在云领域中有着独特的地位,有能力成为行业的领导者。通过并行查询(PQ)提高性能提高性能的一个通用方法是并行,并行可以在多层上实现,GaussDB(for MySQL)允许使用多个线程并行执行单个查询;另一个允许更高并行力度的层是存储层,因为存储系统可能有数百个节点和数千个核心,GaussDB(for MySQL)使用的这种云规模的分布式存储是提高查询性能的一个关键基础,结合并行查询,实现查询性能的极大提高。算子下推(NDP)加速查询效率 GaussDB(for MySQL)通过算子下推(NDP)技术,把算子卸载到数据所在的存储节点上,利用当地可用的计算资源执行,无需将数据读到计算节点中。这样实现了在大规模查询场景中将90%的逻辑计算在分布式存储层完成,大幅度降低了网络I/O 延迟,充分释放了云计算算力,在TPC-H测试中,相比社区版本,其性能最高提升了34倍。秒级伸缩,应用0感知 GaussDB(for MySQL)支持Serverless,根据数据容量自动伸缩,存储自动打散负载压力,无需分库分表。HTAP 只读分析 用户既能得到MySQL完备的事务保障,又能享受到GaussDB(for MySQL) HTAP只读分析的极致分析性能。华为云GaussDB(for MySQL)不仅通过分布式全并行架构和多节点写入提供极致的吞吐量性能,轻松应对海量高并发数据处理,提升高可用能力;还具备跨AZ部署、跨region容灾、单点故障0中断等多个特性,满足金融级别的高可靠性;且仅需要商用数据库1/10的成本就可以提供企业级的服务能力。极致性价比、AI 自治、HTAP、多主、Serverless将是GaussDB(for MySQL) 数据库未来的重点发展方向。 大浪淘沙 做千行百业上云优选 当前, GaussDB(for MySQL)数据库面向企业云原生赛道,已在音视频、互联网电商、游戏、保险、汽车制造、物流、交通出行等多个行业场景和标杆大客户得到广泛应用,包括助力永安保险重构核心业务系统,帮助互联网电商如梦饷集团、单创、未来一手等缔造电商新时代,赋能中国一汽红旗和一汽大众数字化转型等等。在中国一汽红旗ERP系统微服务改造、业务上云过程中,GaussDB(for MySQL)提供了在云上和本地部署体验一致的云数据库服务,改造后的ERP系统数据库整体性能大幅提升,流量洪峰下业务运行又快又稳。梦饷集团通过GaussDB(for MySQL)进行电商平台的数字化升级,将业务搬迁上云后,运维效率提升了约30%,核心业务数据库访问平均耗时由1.5s降至1s;此外,梦饷集团每秒成交的订单数再创历史新高,成为了利用数字基础设施助力业务快速增长的标杆。 持续深耕 共促产业生态繁荣 华为云GaussDB已连续两年入选Gartner云数据库管理系统魔力象限特定领域者,在IDC《2020年下半年中国关系型数据库软件市场数据跟踪报告》中,GaussDB拥有中国关系型数据库本地部署市场国产数据库份额NO.1、公有云市场数据库份额增速第一的优异成绩。 此次奖项的获得是对GaussDB技术创新实力的高度认可,同时也是新征程和新起点。未来,华为云GaussDB将持续聚焦云原生数据库技术的探索,打造更多业界领先的数据库技术与产品,助力企业加速上云,共促产业生态繁荣!
  • [技术干货] 数据库杂谈 | MySQL在中国的境遇
    MySQL可能是很多数据库从业者的启蒙数据库。DB-Engines官网6月最新数据显示,MySQL是全球最受欢迎的开源数据库。在所有数据库排名中,MySQL仅次于Oracle,稳居全球数据库亚军之位。近年来,开源数据库成为数据库发展的一大趋势,备受关注。今天,我们就来扒一扒开源数据库“课代表”MySQL的前世今生。数据库“老炮儿”MySQL发家史▶︎ 数据库“老炮儿”MySQLMySQL的历史最早可以追溯到1979年,距今已有43年历史。1996年10月,MySQL的首个稳定版本 3.11.1发布。此时正值互联网发展初期,一切充满着希望。1999年,瑞典MySQL AB公司成立。进入新世纪,MySQL迈出了重要一步。2000年,MySQL采用GPL(General Public License)许可协议开源。2005年10月,发布了MySQL 5.0,在5.0中加入了游标、存储过程、触发器、视图和事务支持等功能模块。至此,MySQL正式进入高性能数据库行列。2006年,Oracle收购InnoDB引擎,这深刻影响了后来MySQL的发展——因为MySQL被卖身两次后归于Oracle麾下。2008年,瑞典MySQL AB公司被Sun收购。次年,Sun被Oracle收购,MySQL数据库被一并纳入Oracle,进入Oracle MySQL时代。2010年发布的MySQL5.5版本中,将其默认的存储引擎由MyISAM更换为InnoDB。进入移动互联网时代后,MySQL发布了稳定的经典版本:2013年发布MySQL 5.6;2015年发布MySQL 5.7;2018年4月,MySQL 8.0正式发行(GA);MySQL的最新版本8.0.29于2022年4月26日正式发行(GA)。▶︎ 流行:数据库领域的“万人迷”当您浏览本文的时候,后台很可能由MySQL数据库在提供支撑。MySQL的应用十分广泛。新世纪初期,未来的互联网巨头刚刚萌芽,但是商业数据库太过昂贵,对技术人员的能力要求也较高,开源数据库成为大家的新选择。全球范围内,美国雅虎公司率先大规模使用MySQL数据库。在其影响下,海内外互联网公司开始自己的MySQL应用之路,如Google、Facebook、阿里巴巴、百度、腾讯等公司以及90%以上的互联网公司都会或多或少地应用MySQL数据库。自此,以 MySQL 为代表的开源数据库产品引领了数据库技术发展方向,在解决客户需求的同时,也培育了客户使用习惯,从而赢得了大量客户。无论在海外还是中国,MySQL都是最流行的开源数据库,拥有广泛的受众,是数据库领域的“万人迷”。从DB-Engines流行度趋势图可以看到,MySQL与Oracle几乎不相上下。与此同时,MySQL也是全球最受欢迎的关系型数据库之一。根据Slintel网站的统计数据,在全球关系型数据库市场中,MySQL市场份额最高,达到43.04%,Oracle仅为16.76%。中国信息通信研究院《数据库发展研究报告(2021年)》指出,我国金融行业各类数据库应用占比为Oracle 55%、DB2 19%、MySQL 13%、PostgreSQL 6%,其他7%。那么,MySQL是如何成为数据库领域的“万人迷”呢?▶︎ 借势互联网,开源、免费成就全球最受欢迎的关系型数据库MySQL能成为全球最受欢迎的关系型数据库,主要是搭上了互联网爆发时代的快车。MySQL本身产品能力过硬,凭借开源、免费的优势,从Oracle、DB2等成熟的商业数据库丛林中,硬是杀出了一条血路。开源与互联网相互促进,彼此成就。开源软件可以看作是分布式协作的标杆,即利用全人类的智慧群策群力。源代码开放具备全球共享、免费等特点,使更多人参与到软件开发中。而互联网的发展则打破了时空的界限,将全球链接到一起,使全球分布式协作更高效便捷。MySQL数据库凭借其性能稳定、成本低、高可用、生态成熟等优势,俘获了无数开源贡献者的心,成为数据库领域的“万人迷”。从MySQL的发展史不难看出,MySQL数据库的核心动力源于开源贡献者。即便2009年,MySQL创始人Monty Widenius离开Sun独自进行MySQL重要分支MariaDB的开发,仍无法撼动MySQL全球第一开源数据库的地位。但近年来,随着MySQL兼容外部开源贡献者的态度日趋保守,MySQL原有拥趸转投MariaDB、Percona Server,导致MySQL占有率逐渐下降也是不争的事实。MySQL与中国的故事▶︎ 曾经的MySQL中国研发中心和MySQL中国教育中心中国最早的一批MySQL数据库从业者一定会记得MySQL中国研发中心和MySQL中国教育中心。早在2005年,中国企业北京万里开源软件有限公司(简称“万里数据库”)就与瑞典MySQL AB公司成立了MySQL中国研发中心和MySQL中国教育中心,共同推动MySQL在中国的发展。万里数据库与MySQL的合作直至2009年底终止。此后,MySQL的服务授权由Oracle授予,国内也有不少企业获得了MySQL的技术服务授权,其中较为典型的厂商如爱可生。▶︎ 国产数据库中MySQL技术路线占比高国内最早的一批互联网先行者是推动MySQL在中国发展的重要力量。以互联网巨头阿里巴巴为例,当年基于成本与安全的考虑,提出“去IOE”的口号。其中去“O”就是以MySQL替代Oracle。基于MySQL发展出的AliSQL独立分支,在阿里去“O”工程中发挥了重要作用。而基于对MySQL改造的实践,阿里巴巴影响和带动了国内互联网公司应用MySQL的热潮。MySQL 是目前世界上最流行的开源数据库软件,市场占有率巨大,这是不可否认的事实。我们再从数据库产品本身、用户使用等方面看看国内MySQL的发展情况。当前是国产数据库发展的黄金时期,百花齐放,异彩纷呈。我国关系型数据库产品多数基于 MySQL 二次开发而来。根据中国信息通信研究院《数据库发展研究报告(2021年)》,截止到2021年6月,关系型数据库中有23个是基于开源数据库 MySQL 进行二次开发的,占关系型数据库的比例为 28.40%。国内各行各业的终端用户也大量使用了 MySQL 数据库。以金融行业为例,据调研,90%的金融机构已广泛应用或试用开源软件。开源数据库方面,超9成金融机构应用了MySQL数据库。目前,MySQL数据库已在金融行业得到了规模化应用。工商银行、建设银行、招商银行、民生银行、中国银联、泰康保险6家金融企业的MySQL数据库投产节点规模超过1000个。其中,中国银联、工商银行、招商银行甚至超过4000个节点。与之相对应的是国内围绕MySQL生态的长期投入,如基础软硬件设施、适配 MySQL 的应用软件开发、MySQL 生态的人才培养等。在此基础上,国内已形成了庞大的围绕 MySQL 的软件生态和人才生态,大量的终端用户把 MySQL 作为首选数据库软件进行使用。虽然MySQL的开源协议会造成业内的一些担忧,但正确的做法不是放弃,而是规范应用和技术掌控,而且以MySQL为代表的开源数据库也迎来了政策东风。▶︎ 国家政策大力扶持开源项目,为国内厂商保驾护航中国信息通信研究院《开源生态白皮书2021》指出,我国已成为全球开源生态的重要贡献力量,参与国际开源社区协作的开发者数量排名全球第二。国内开源技术空前发展的同时,具有引领性、保障性的政策出台也带来了利好。2021年,开源被首次写入《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》,明确提出支持数字技术开源社区等创新联合体发展;同年10月,央行、网信办、工信部、银保监会、证监会联合发布《关于规范金融业开源技术应用与发展的意见》,为开源在金融业的应用提供政策指引;工信部也印发《“十四五”软件和信息技术服务业发展规划》,系统布局“十四五”开源生态发展;2022年,国务院又印发《“十四五”数字经济发展规划》,提出支持具有自主核心技术的开源社区、开源平台、开源项目发展等规划。 相信这些纲领性的政策及后续的实施指南将对我国开源技术的良性发展起到保驾护航的作用。随着国家对开源技术的重视,开源项目及开源协议的合规性也必将作为重点规范内容,以保障我国企业对开源技术的应用。▶︎ 国内MySQL技术路线发展的未来近年来,国内基于MySQL技术路线或兼容MySQL的社区逐渐兴起。相比国外MySQL开源社区,国内MySQL技术相关的社区主要由国内厂商、技术人员参与并进行代码贡献,相对更自主、安全、可控。目前,国内开源数据库社区中,明确提出基于MySQL路线的开源社区并不多,大多是兼容MySQL的开源数据库社区,如:TiDB社区、OceanBase社区。GreatSQL社区是国内为数不多的、明确基于MySQL路线且较为活跃的开源数据库社区。该社区成立于2021年,由万里数据库发起。从官方资料可以看到GreatSQL分支与MySQL官方的差异及优势特性。GreatSQL开源数据库是适用于金融级应用的国内自主MySQL版本,专注于提升MGR可靠性及性能,支持InnoDB并行查询等特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。据了解,GreatSQL社区已覆盖1500+技术开发者,被Gitee评为“最有价值开源项目”。除MySQL数据库技术分支项目本身外,MySQL技术周边工具的开源项目在国内出现更早,如爱可生开源社区。它并不对数据库本身进行改造开源,而是对数据库周边工具进行开源,这也是繁荣国内MySQL技术路线的一种积极力量。以MySQL为代表的开源数据库引领了一个时代,所沉淀下的优秀资产和强大生态也会继续在国内数据库市场上发光发热。相信在国家政策的引领下,在国内无数MySQL技术人员的努力贡献下,国产MySQL技术路线的数据库乃至整个开源数据库,未来都将大有可为。来源:ITPUB
  • [最佳实践] 创建Flink OpenSource作业从MySQL CDC源表读取数据写入到DWS
    场景描述CDC是变更数据捕获(Change Data Capture)技术的缩写,它可以将源数据库的增量变动记录,同步到一个或多个数据目的中。CDC在数据同步过程中,还可以对数据进行一定的处理,例如分组(GROUP BY)、多表的关联(JOIN)等。本示例通过创建MySQL CDC源表来监控MySQL的数据变化,并将变化的数据信息插入到DWS数据库中。前提条件已创建RDS MySQL实例,具体步骤可参考:RDS MySQL快速入门。本示例创建的RDS MySQL数据库版本选择为:8.0。已创建DWS实例,具体创建DWS集群的操作可以参考创建DWS集群。本示例创建的DWS集群版本为:8.1.1.205。整体作业开发流程整体作业开发流程参考图1。图1 作业开发流程步骤1:创建队列:创建DLI作业运行的队列。步骤2:创建RDS MySQL数据库和表:创建RDS MySQL的数据库和表。步骤3:创建DWS数据库和表:创建用于接收数据的DWS数据库和表。步骤4:创建增强型跨源连接:DLI上创建连接RDS和DWS的跨源连接,打通网络。步骤5:运行作业:DLI上创建和运行Flink OpenSource作业。步骤6:发送数据和查询结果:RDS MySQL的表上插入数据,在DWS上查看运行结果。步骤1:创建队列登录DLI管理控制台,在左侧导航栏单击“资源管理 > 队列管理”,可进入队列管理页面。在队列管理界面,单击界面右上角的“购买队列”。在“购买队列”界面,填写具体的队列配置参数,具体参数填写参考如下。计费模式:选择“包年/包月”或“按需计费”。本示例选择“按需计费”。区域和项目:保持默认值即可。名称:填写具体的队列名称。说明:新建的队列名称,名称只能包含数字、英文字母和下划线,但不能是纯数字,且不能以下划线开头。长度限制:1~128个字符。队列名称不区分大小写,系统会自动转换为小写。类型:队列类型选择“通用队列”。“按需计费”时需要勾选“专属资源模式”。AZ策略、CPU架构、规格:保持默认即可。企业项目:当前选择为“default”。高级选项:选择“自定义”。网段:配置队列网段。例如,当前配置为10.0.0.0/16。注意:队列的网段不能和DMS Kafka、RDS MySQL实例的子网网段有重合,否则后续创建跨源连接会失败。其他参数根据需要选择和配置。图2 创建队列参数配置完成后,单击“立即购买”,确认配置信息无误后,单击“提交”完成队列创建。步骤2:创建RDS MySQL数据库和表登录RDS管理控制台,在“实例管理”界面,选择已创建的RDS MySQL实例,选择操作列的“更多 > 登录”,进入数据管理服务实例登录界面。输入实例登录的用户名和密码。单击“登录”,即可进入RDS MySQL数据库并进行管理。在数据库实例界面,单击“新建数据库”,数据库名定义为:testrdsdb,字符集保持默认即可。在已创建的数据库的操作列,单击“SQL查询”,输入以下创建表语句,创建RDS MySQL表。CREATE TABLE mysqlcdc ( `order_id` VARCHAR(64) NOT NULL, `order_channel` VARCHAR(32) NOT NULL, `order_time` VARCHAR(32), `pay_amount` DOUBLE, `real_pay` DOUBLE, `pay_time` VARCHAR(32), `user_id` VARCHAR(32), `user_name` VARCHAR(32), `area_id` VARCHAR(32) ) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8mb4;步骤3:创建DWS数据库和表参考使用gsql命令行客户端连接DWS集群连接已创建的DWS集群。执行以下命令连接DWS集群的默认数据库“gaussdb”:gsql -d gaussdb -h DWS集群连接地址 -U dbadmin -p 8000 -W password -rgaussdb:DWS集群默认数据库。DWS集群连接地址:请参见获取集群连接地址进行获取。如果通过公网地址连接,请指定为集群“公网访问地址”或“公网访问域名”,如果通过内网地址连接,请指定为集群“内网访问地址”或“内网访问域名”。如果通过弹性负载均衡连接,请指定为“弹性负载均衡地址”。dbadmin:创建集群时设置的默认管理员用户名。-W:默认管理员用户的密码。在命令行窗口输入以下命令创建数据库“testdwsdb”。CREATE DATABASE testdwsdb;执行以下命令,退出gaussdb数据库,连接新创建的数据库“testdwsdb”。\q gsql -d testdwsdb -h DWS集群连接地址 -U dbadmin -p 8000 -W password -r执行以下命令创建表。create schema test; set current_schema= test; drop table if exists dwsresult; CREATE TABLE dwsresult ( car_id VARCHAR, car_owner VARCHAR, car_age INTEGER , average_speed FLOAT8, total_miles FLOAT8 );步骤4:创建增强型跨源连接创建DLI连接RDS的增强型跨源连接在RDS管理控制台,选择“实例管理”,单击对应的RDS实例名称,进入到RDS的基本信息页面。在“基本信息”的“连接信息”中获取该实例的“内网地址”、“数据库端口”、“虚拟私有云”和“子网”信息,方便后续操作步骤使用。单击“连接信息”中的安全组名称,在“入方向规则”中添加放通队列网段的规则。例如,本示例队列网段为“10.0.0.0/16”,则规则添加为:优先级选为:1,策略选为:允许,协议选择:TCP,端口值不填,类型:IPV4,源地址为:10.0.0.0/16,单击“确定”完成安全组规则添加。登录DLI管理控制台,在左侧导航栏单击“跨源管理”,在跨源管理界面,单击“增强型跨源”,单击“创建”。在增强型跨源创建界面,配置具体的跨源连接参数。具体参考如下。连接名称:设置具体的增强型跨源名称。本示例输入为:dli_rds。弹性资源池:选择步骤1:创建队列中已经创建的队列。虚拟私有云:选择RDS的虚拟私有云。子网:选择RDS的子网。其他参数可以根据需要选择配置。参数配置完成后,单击“确定”完成增强型跨源配置。单击创建的跨源连接名称,查看跨源连接的连接状态,等待连接状态为:“已激活”后可以进行后续步骤。单击“队列管理”,选择操作的队列,本示例为步骤1:创建队列中创建的队列,在操作列,单击“更多 > 测试地址连通性”。在“测试连通性”界面,根据2中获取的RDS连接信息,地址栏输入“RDS内网地址:RDS数据库端口”,单击“测试”测试DLI到RDS网络是否可达。创建DLI连接DWS的增强型跨源连接在DWS管理控制台,选择“集群管理”,单击已创建的DWS集群名称,进入到DWS的基本信息页面。在“基本信息”的“数据库属性”中获取该实例的“内网IP”、“端口”,“基本信息”页面的“网络”中获取“虚拟私有云”和“子网”信息,方便后续操作步骤使用。单击“连接信息”中的安全组名称,在“入方向规则”中添加放通队列网段的规则。例如,本示例队列网段为“10.0.0.0/16”,则规则添加为:优先级选为:1,策略选为:允许,协议选择:TCP,端口值不填,类型:IPV4,源地址为:10.0.0.0/16,单击“确定”完成安全组规则添加。登录DLI管理控制台,在左侧导航栏单击“跨源管理”,在跨源管理界面,单击“增强型跨源”,单击“创建”。说明:本示例默认RDS和DWS实例分别在两个VPC和子网下,所以要分别创建增强型跨源连接打通网络。如果RDS和DWS实例属于同一VPC和子网下,则创建增强型跨源一次即可,4和5不需要再执行。在增强型跨源创建界面,配置具体的跨源连接参数。具体参考如下。连接名称:设置具体的增强型跨源名称。本示例输入为:dli_dws。弹性资源池:选择步骤1:创建队列中已经创建的队列。虚拟私有云:选择DWS的虚拟私有云。子网:选择DWS的子网。其他参数可以根据需要选择配置。参数配置完成后,单击“确定”完成增强型跨源配置。单击创建的跨源连接名称,查看跨源连接的连接状态,等待连接状态为:“已激活”后可以进行后续步骤。单击“队列管理”,选择操作的队列,本示例为步骤1:创建队列中创建的队列,在操作列,单击“更多 > 测试地址连通性”。在“测试连通性”界面,根据2中获取的DWS连接信息,地址栏输入“DWS内网IP:DWS端口”,单击“测试”测试DLI到DWS网络是否可达。步骤5:运行作业在DLI管理控制台,单击“作业管理 > Flink作业”,在Flink作业管理界面,单击“创建作业”。在创建队列界面,类型选择“Flink OpenSource SQL”,名称填写为:FlinkCDCMySQLDWS。单击“确定”,跳转到Flink作业编辑界面。在Flink OpenSource SQL作业编辑界面,配置如下参数。所属队列:选择步骤1:创建队列中创建的队列。Flink版本:选择1.12。保存作业日志:勾选。OBS桶:选择保存作业日志的OBS桶,根据提示进行OBS桶权限授权。开启Checkpoint:勾选。Flink作业编辑框中输入具体的作业SQL,本示例作业参考如下。SQL中加粗的参数需要根据实际情况修改。说明:本示例使用的Flink版本为1.12,故Flink OpenSource SQL语法也是1.12。本示例数据源是Kafka,写入结果数据到Elasticsearch,故请参考Flink OpenSource SQL 1.12创建MySQL CDC源表和Flink OpenSource SQL 1.12创建DWS结果表。create table mysqlCdcSource( order_id string, order_channel string, order_time string, pay_amount double, real_pay double, pay_time string, user_id string, user_name string, area_id STRING ) with ( 'connector' = 'mysql-cdc', 'hostname' = '192.168.12.148',--IP替换为RDS MySQL的实例IP 'port' = '3306',--端口替换为RDS MySQL的实例端口 'username' = 'xxx',--RDS MySQL实例的数据库用户名 'password' = 'xxx',--RDS MySQL实例的数据库用户密码 'database-name' = 'testrdsdb',--RDS MySQL实例的数据库名 'table-name' = 'mysqlcdc'--RDS MySQL实例的数据库下的表名 ); create table dwsSink( order_channel string, pay_amount double, real_pay double, primary key(order_channel) not enforced ) with ( 'connector' = 'gaussdb', 'driver' = 'com.huawei.gauss200.jdbc.Driver', 'url' = 'jdbc:gaussdb://192.168.168.16:8000/testdwsdb', ---192.168.168.16:8000替换为DWS的内网IP和端口,testdwsdb为创建的DWS数据库名 'table-name' = 'test\".\"dwsresult', ---test为创建的DWS表的schema,dwsresult为对应的DWS表名 'username' = 'xxx',--替换为DWS实例的用户名 'password' = 'xxx',--替换为DWS实例的用户密码 'write.mode' = 'insert' ); insert into dwsSink select order_channel, sum(pay_amount),sum(real_pay) from mysqlCdcSource group by order_channel;单击“语义校验”确保SQL语义校验成功。单击“保存”,保存作业。单击“启动”,启动作业,确认作业参数信息,单击“立即启动”开始执行作业。等待作业运行状态变为“运行中”。步骤6:发送数据和查询结果登录RDS管理控制台,在“实例管理”界面,选择已创建的RDS MySQL实例,选择操作列的“更多 > 登录”,进入数据管理服务实例登录界面。输入实例登录的用户名和密码。单击“登录”,即可进入RDS MySQL数据库并进行管理。在已创建的数据库的操作列,单击“SQL查询”,输入以下创建表语句,插入测试数据。insert into mysqlcdc values ('202103241000000001','webShop','2021-03-24 10:00:00','100.00','100.00','2021-03-24 10:02:03','0001','Alice','330106'), ('202103241206060001','appShop','2021-03-24 12:06:06','200.00','180.00','2021-03-24 16:10:06','0002','Jason','330106'), ('202103241403000001','webShop','2021-03-24 14:03:00','300.00','100.00','2021-03-24 10:02:03','0003','Lily','330106'), ('202103241636060001','appShop','2021-03-24 16:36:06','200.00','150.00','2021-03-24 16:10:06','0001','Henry','330106');参考使用gsql命令行客户端连接DWS集群连接已创建的DWS集群。执行以下命令连接DWS集群的默认数据库“testdwsdb”:gsql -d testdwsdb -h DWS集群连接地址 -U dbadmin -p 8000 -W password -r执行以下命令,查询DWS的表数据。select * from test.dwsresult;查询结果参考如下:order_channel pay_amount real_pay appShop 400.0 330.0 webShop 400.0 200.0
  • [交流吐槽] 彻底根除MySQL慢查询,这12个问题都不能落下
    前言日常开发中,我们经常会遇到数据库慢查询。那么导致数据慢查询都有哪些常见的原因呢?今天田螺哥就跟大家聊聊导致MySQL慢查询的12个常见原因,以及对应的解决方法。一、SQL没加索引1、反例select * from user_info where name ='dbaplus社群' ;2、正例//添加索引 alter table user_info add index idx_name (name);二、SQL 索引不生效有时候我们明明加了索引了,但是索引却不生效。在哪些场景,索引会不生效呢?主要有以下十大经典场景:1、隐式的类型转换,索引失效我们创建一个用户user表。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, userId varchar(32) NOT NULL, age varchar(16) NOT NULL, name varchar(255) NOT NULL, PRIMARY KEY (id), KEY idx_userid (userId) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;userId字段为字串类型,是B+树的普通索引,如果查询条件传了一个数字过去,会导致索引失效。如下:如果给数字加上'',也就是说,传的是一个字符串呢,当然是走索引,如下图:为什么第一条语句未加单引号就不走索引了呢?这是因为不加单引号时,是字符串跟数字的比较,它们类型不匹配,MySQL会做隐式的类型转换,把它们转换为浮点数再做比较。隐式的类型转换,索引会失效。2、查询条件包含or,可能导致索引失效我们还是用这个表结构:CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, userId varchar(32) NOT NULL, age varchar(16) NOT NULL, name varchar(255) NOT NULL, PRIMARY KEY (id), KEY idx_userid (userId) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;其中userId加了索引,但是age没有加索引的。我们使用了or,以下SQL是不走索引的,如下:对于or+没有索引的age这种情况,假设它走了userId的索引,但是走到age查询条件时,它还得全表扫描,也就是需要三步过程:全表扫描+索引扫描+合并。如果它一开始就走全表扫描,直接一遍扫描就完事。Mysql优化器出于效率与成本考虑,遇到or条件,让索引失效,看起来也合情合理嘛。注意:如果or条件的列都加了索引,索引可能会走也可能不走,大家可以自己试一试哈。但是平时大家使用的时候,还是要注意一下这个or,学会用explain分析。遇到不走索引的时候,考虑拆开两条SQL。3、like通配符可能导致索引失效并不是用了like通配符,索引一定会失效,而是like查询是以%开头,才会导致索引失效。like查询以%开头,索引失效。explain select * from user where userId like '%123';把%放后面,发现索引还是正常走的,如下:既然like查询以%开头,会导致索引失效。我们如何优化呢?使用覆盖索把%放后面4、查询条件不满足联合索引的最左匹配原则MySQl建立联合索引时,会遵循最左前缀匹配的原则,即最左优先。如果你建立一个(a,b,c)的联合索引,相当于建立了(a)、(a,b)、(a,b,c)三个索引。假设有以下表结构:CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, user_id varchar(32) NOT NULL, age varchar(16) NOT NULL, name varchar(255) NOT NULL, PRIMARY KEY (id), KEY idx_userid_name (user_id,name) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;有一个联合索引idx_userid_name,我们执行这个SQL,查询条件是name,索引是无效:explain select * from user where name ='dbaplus社群';因为查询条件列name不是联合索引idx_userid_name中的第一个列,索引不生效在联合索引中,查询条件满足最左匹配原则时,索引才正常生效。5、在索引列上使用mysql的内置函数表结构:CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` varchar(32) NOT NULL, `login_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) USING BTREE, KEY `idx_login_time` (`login_Time`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;虽然login_time加了索引,但是因为使用了mysql的内置函数Date_ADD(),索引直接GG,如图:一般这种情况怎么优化呢?可以把内置函数的逻辑转移到右边,如下:6、对索引进行列运算(如,+、-、*、/),索引不生效表结构:CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` varchar(32) NOT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_age` (`age`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;虽然age加了索引,但是因为它进行运算,索引直接迷路了。如图:所以不可以对索引列进行运算,可以在代码处理好,再传参进去。
总条数:813 到第
上滑加载中