所以说，当公司业务有跨库分析时（一般情况是，业务数据库分布在各个部门），一些数据需要配合其他部门的数据进行关联查询，这个时候可以考虑Presto。但是目前，对于MySQL统计查询在性能上有瓶颈。可考虑将数据按时间段归档到HDFS中，以提高统计效率。
很多的时候，在Presto上对数据库跨库查询，例如Mysql数据库。这个时候Presto的做法是从MySQL数据库端拉取最基本的数据，然后再去做进一步的处理，例如统计等聚合操作。
最近由于业务需求，需要将公有云RDS（业务库）的大表数据归档至私有云MySQL（历史库），以缩减公有云RDS的体积和成本。
“增删改查”都是查找问题，因为你都得先找到数据才能对数据做操作。那存储系统性能问题，其实就是查找快慢问题。
当我们业务数据库表中的数据越来越多，如果你也和我遇到了以下类似场景，那让我们一起来解决这个问题
如果将应用的所有数据简单地放在一台 MySQL 服务器实例上，就不用谈什么扩展性了。但是业务能稳定持续的增长，那么应用肯定会碰到性能瓶颈。
使用起来和不分区是一样的，看起来只有一个数据库，其实有多个分区文件，比如我们要插入一条数据，不需要指定分区，MySQL会自动帮我们处理
在工单详情可快速提交相同SQL内容到其他实例，可适用于test>beta>ga等多套环境维护的需求
业务不断地在增长，集群分片中的数据也会随着时间的推移而增加，其中有相当一部分的数据是很少被使用的，例如几年前的订单记录、交易记录、商品评论等数据。这部分数据就称之为冷数据，与之相反经常被使用的数据则称之为热数据。
◆ 冷热分离 本文讲的第一个场景是冷热分离。简单来说，就是将常用的“热”数据和不常使用的“冷”数据分开存储。 本章要考虑的重点是锁的机制、批量处理以及失败重试的数据一致性问题。这部分内容在实际开发中的“陷阱”还是不少的。 首先介绍一下业务场景。 ◆ 1.1 业务场景：几千万数据量的工单表如何快速优化 这次项目优化的是一个邮件客服系统。它是一个SaaS（通过网络提供软件服务）系统，但是大客户只有两三家，最主要的客户是一家大型媒体集团。 这个系统的主要功能是这样的：它会对接客户的邮件服务器，自动收取发到几个
现在业务系统设计中，存储设计扮演着至关重要的角色。随着数据量的爆炸性增长和业务需求的不断变化，如何高效、安全地存储和管理数据成为了每个业务系统设计必须面对的挑战。
Percona Toolkit 神器全攻略系列共八篇，前文回顾： 前文回顾Percona Toolkit 神器全攻略 全文约定：$为命令提示符、greatsql>为GreatSQL数据库提示符。在后续阅读中，依据此约定进行理解与操作 实用类 在Percona Toolkit中实用类共有以下工具
作为一个后端工程师，想必没有人没用过数据库，跟我一起复习一下MySQL吧，本文是我学习《MySQL实战45讲》的总结笔记的第一篇，总结了MySQL的基础架构、一个查询语句的执行过程 以及 一条更新语句的执行过程。
究竟哪些东西可以影响到我们服务器的性能呢？ 无非就是：CPU、磁盘IO、内存等等一系列硬件 在研究性能时候,先带大家来了解三个术语 QPS: 每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,简言之就是数据库每秒能查多少数据 TPS: 服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS） 并发量: 同一时间处理请求的数量，注意不要和同时连接数搞混,连接数要比并发量多的多的多 如果存
MySQL数据库归档历史数据主要可以分为三种方式：一.创建编写SP、设置Event；二.通过dump导入导出；三.通过pt-archiver工具进行归档。第一种方式往往受限于同实例要求，往往被大家舍弃。第二种，性能相对较好，但是归档表较多时运维也是比较头疼的事。所以很多DBA往往采用第三种方式--pt-archiver。
目前一共包含6个脚本，若脚本的扩展名为“.sql”则表示该脚本为sql脚本，若脚本的扩展名为“.pl”则表示该脚本为perl脚本。
一般现在对于业务要查询的数据量以及要保持的并发量高于一定配置的单实例 MySQL 的极限的情况，都会采取分库分表的方案解决。当然，现在也有很多 new SQL 的分布式数据库的解决方案，如果你用的是 MySQL，那么你可以考虑 TiDB（实现了 MySQL 协议，兼容 MySQL 客户端以及 SQL 语句）。如果你用的是的 PgSQL，那么你可以考虑使用 YugaByteDB（实现了 PgSQL 协议，兼容 PgSQL 客户端以及 SQL 语句），他们目前都有自己的云部署解决方案，你可以试试：
查询缓存: 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。
目前，在很多OLTP场景中，MySQL数据库都有着广泛的应用，也有很多不同的使用方式。从数据库的业务需求、架构设计、运营维护、再到扩容迁移，不同的MySQL架构有不同的特点，适应一定的业务场景，或者解决一定的业务问题。
数据库运行久了, 日志就很多, 很占空间. 就需要定期清理, 人工清理一是麻烦, 二是容易出错
# tar -zxvf percona-toolkit-2.2.17.tar.gz # yum -y install perl perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl-TermReadKey # yum -y install perl-Digest-MD5
在以往的一些面试过程中，我发现了一些有趣的回答，它们很容易被为归类为“错误答案”。但有时，这些答案却发人深省或包含深刻的含义。本文涉及一些常见的 MySQL 问答，这些问答可能看起来“错误”或“有趣”，但实际上还有更多内容。我将分享一些看似“错误”或异想天开的答案，并仔细研究它们提供的宝贵经验和观点。
最近一直在写《手撕MySQL系列》文章，我发现自己的切入点有一些问题，虽尝试深入探究MySQL中的一些关键特性，但对于MySQL的知识掌握不太能够形成较好的体系化的知识网络。我感到在对全局了解不够清晰的时候，去深究一个知识点往往会事倍功半。所以打算通过这篇文章，分析SQL语句从头到尾的执行，串连一下MySQL当中的基础知识点。
存储引擎，就是如何存储数据、如何更新数据、如何查询数据、如何为存储的数据建立索引等一系列技术的实现方法。可以通过 show engines; 语句查看mysql支持的存储引擎。 mysql 常用存储引擎：
存储引擎，就是如何存储数据、如何更新数据、如何查询数据、如何为存储的数据建立索引等一系列技术的实现方法。可以通过 show engines; 语句查看mysql支持的存储引擎。
一个更新语句执行的时候整个过程跟查询的步骤是类似的，具体可以看之前的文章：MySQL实战 | MySQL逻辑架构—一条查询SQL是如何执行的，在一个表上有更新的时候，跟这个表有关的查询缓存会失效，所以这条语句就会把表上所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因。 根据id更新某条数据，分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用 ID 这个索引。然后，执行器负责具体执行，找到这一行，然后更新。 与查询流程不一样的是，更新流程还涉及两个重要的日志模块：redo log（重做日志）和 binlog（归档日志）。
当我们需要修改一个记录时，数据库会先根据条件找到要修改的数据，然后执行修改写入操作，因此我们再分析写操作的执行过程时，其实是包含读语句的执行过程的。
一、什么是执行计划？ 1）执行计划 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。 可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要： a、SQL语句是否清晰地告诉查询优化器它想干什么？ b、查询优化器得
LCS 是一个基于 Python Django 框架的项目，业务核心是物流订单的履约过程，包括连接上游和第三方物流服务的创建订单、轨迹与运费更新。在部署上，LCS 依据业务所在的市场不同，应用层分市场部署，并使用各自市场对应的数据库。在项目起步初期，这些不同市场的数据库共用同一套物理集群，共享内存和磁盘空间，在资源上看，是足以应付初期流量的。
sql 语句分为两种，一种是查询，一种是更新（增加，更新，删除）。先分析下查询语句，语句如下：
本文详细介绍了转转业财系统亿级数据存储优化的实践。面对系统数据量大、慢查询多等挑战，转转业财采取了 TiDB 方案优化数据量问题，同时引入 Elasticsearch（ES）解决慢查询难题。实践表明，通过底层数据存储切换和 ES 接入，系统成功突破了存储瓶颈，显著提升了查询效率和响应速度，为大规模数据处理提供了有效的优化路径。
在以MySQL为主要存储组件的业务系统中，MySQL的性能直接影响到应用的响应速度、用户体验和系统的可扩展性。因此，优化数据库的性能，特别是SQL查询的执行效率，成为了提升整个应用性能的关键环节。
背景 从MySQL.slow_log 获取慢查询日志很慢，该表是csv表，没有索引。 想添加索引来加速访问，而csv引擎不能添加索引（csv引擎存储是以逗号分割的文本来存储的），只能改存储引擎来添加索引了 mysql.slow_log表能改成myisam，不能改成innodb 📷 mysql> set global slow_query_log=off; Query OK, 0 rows affected (0.00 sec) mysql> alter table mysql.slow_log en
分区是一种表的设计模式，通俗地讲表分区是将一大表，根据条件分割成若干个小表。但是对于应用程序来讲，分区的表和没有分区的表是一样的。换句话来讲，分区对于应用是透明的，只是数据库对于数据的重新整理。本篇文章给大家带来的内容是关于MySQL中分区表的介绍及使用场景，有需要的朋友可以参考一下，希望对你有所帮助。
我们都知道，在Mysql 中，如果数据量过大的话，就有可能在查询过程中会出现各种超时的情况，毕竟如果一个表的数据量过大的时候，一个简单的单表查询都会有点慢，所以，就有了各种中间件的存在，比如说 MyCat，ShardingJDBC 等分库工具，但是今天了不起不说这个，我们来说说这个Mysql自己的分区，我们不做分库操作。
存储引擎是数据库的核心，MySQL的存储引擎架构被设计为可插拔式架构模式，也就是在不影响任何业务逻辑的情况下，我们可以随时替换当前的存储引擎，以达到以存储和性能方面的需求。
MyISAM表独立于操作系统的，可以轻松移植，建立一个myisam引擎的表时，就会在本地磁盘上建立三个文件，文件名就是表名。（tb_demo.frm存储表定义，tb_demo_MYD,存储数据，tb_demo.MYI,存储索引。） 它无法处理事务。 适用情况 1.选择密集型的表 2.插入密集型的表
-多年互联网运维工作经验，曾负责过大规模集群架构自动化运维管理工作。 -擅长Web集群架构与自动化运维，曾负责国内某大型金融公司运维工作。 -devops项目经理兼DBA。 -开发过一套自动化运维平台（功能如下）： 1)整合了各个公有云API，自主创建云主机。 2)ELK自动化收集日志功能。 3)Saltstack自动化运维统一配置管理工具。 4)Git、Jenkins自动化代码上线及自动化测试平台。 5)堡垒机，连接Linux、Windows平台及日志审计。 6)SQL执行及审批流程。 7)慢查询日志分析web界面。
之前做过一个项目，数据库存储采用的是mysql。当时面临着业务指数级的增长，存储容量不足。当时采用的措施是
◆ 冷热分离二期实现思路：冷数据存放到HBase ◆ 冷热分离一期解决方案的不足 不得不说，冷热分离一期的解决方案确实能解决写操作慢和热数据慢的问题，但仍然存在诸多不足。 1）用户查询冷数据的速度依旧很慢，虽然查询冷数据的用户比例很低。 2）冷数据库偶尔会告警。 这两点不足体现在用户侧是什么样呢？那就是一旦客服在工单查询表中勾选“查询归档”checkBox，页面就会一直转圈，而后台冷数据库的IO就会飙升。 如果客服发现页面没反应，可能会多点几次“查询”按钮，那么有可能把后台服务器的请求线程占满，导致整个系统
前些天处理了一个需求，当时的数据库环境是Oracle，我算是想尽了Oracle相关的方案，而且在问题的处理过程中，还在不断的琢磨，如果失败了还有什么其他的方案。 所以尽管Oracle这么一个成熟的商业数据库，做起来还是有些难度，需要一些额外的技巧，比如规避bug,间接实现需求等。 但是换个角度，2亿多数据的表，其实MySQL也不是新鲜事儿了。如果MySQL碰到了这种情况，该怎么处理呢。 梳理业务需求 假设业务需求还是不变，如下： 业务同学反馈，数据库中有一个表数据量很大，因
mysql是一种开放源代码的关系型数据库管理系统（RDBMS）,是使用最常用的数据库管理语言–结构化查询语言（SQL）进行数据库管理。
之前你可能经常听DBA同事说，MySQL可以恢复到半个月内任意一秒的状态，惊叹的同时，你是不是心中也会不免会好奇，这是怎样做到的呢？
马上消费金融于 2015 年 6 月营业，截止到 2020 年 1 月，历经 4 年多风雨，总注册用户数 8000 万，活跃用户数 2500 万，累计放贷 2900 多亿元人民币。公司于 2018 年 6 月增资到 40 亿，成为内资第一大的消费金融公司。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
