嵌套查询 用一条SQL语句得结果作为另外一条SQL语句得条件，效率不好把握 SELECT * FROM A WHERE id IN (SELECT id FROM B)
写在前面： 博主是一名大数据的初学者，昵称来源于《爱丽丝梦游仙境》中的Alice和自己的昵称。作为一名互联网小白，写博客一方面是为了记录自己的学习历程，一方面是希望能够帮助到很多和自己一样处于起步阶段的萌新。由于水平有限，博客中难免会有一些错误，有纰漏之处恳请各位大佬不吝赐教！个人小站:http://alices.ibilibili.xyz/ , 博客主页:https://alice.blog.csdn.net/ 尽管当前水平可能不及各位大佬，但我还是希望自己能够做得更好，因为一天的生活就是一生的缩影。
老师有个问题想请教一下，我们项目中有个需求是查询出数据集根据某个字段去重后的全部结果，用 collapse 发现很多数据都没查询到，后面发现是去重的这个字段的值太长了，ignore _above默认的是256，而这个字段的值有的有十几万甚至几十万个字符，像这种情况，还有什么比较好的查询去重方法吗？
truncate和不带where子句的delete,以及drop都会删除表内的数据
在MySQL中，索引是在存储引擎层而不是服务器层实现的。所以没用统一的索引标准，不同存储引擎的索引工作方式并不相同。
◆ ClickHouse概念 clickhouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)，由俄罗斯最大的搜索公司Yandex开发，于2016年开源，采用c++开发。 ◆ OLAP 和 OLTP 这两个概念 OLAP（On-Line Analytical Processing）：联机分析处理OLAP（On-Line Analytical Processing),仓库型数据库，主要是读取数据，做复杂数据分析（多维），侧重技术决策支持，提供直观简单的结果,开源OLAP引擎包含Hive、Sp
本文的重点是在合并和连接操作方面比较Pandas和SQL。Pandas是一个用于Python的数据分析和操作库。SQL是一种用于管理关系数据库中的数据的编程语言。两者都使用带标签的行和列的表格数据。
在生产环境中，数据库的主从配置是很有必要的，主从配置能提供数据源的备份，提供安全性方面的保障，从数据库也能减轻主数据库的访问压力，在出现故障时，也能减少损失。文档中会介绍MySQL5.7.22的主从配置步骤。
最近遇到一个业务需求，要统计一张mysql大表每天/每周/每月的记录量（该表每天产生的记录量在好几百万）。当然有朋友会说，select count(1) from xxx 不就完事了吗？
欢迎关注专栏：Java架构技术进阶。里面有大量batj面试题集锦，还有各种技术分享，如有好文章也欢迎投稿哦。 微信公众号：慕容千语的架构笔记。欢迎关注一起进步。
如果一个函数体内有一些条件分支语句，而这些条件分支语句内部散布了一些重复的代码，那么就有必要进行合并去重工作。
innobackupex --user=root --password /fullback
问题1：char、varchar的区别是什么？ varchar是变长而char的长度是固定的。如果你的内容是固定大小的，你会得到更好的性能。
数据库如何判定，当前这一条记录是重复的？先查找，再插入。但是加上约束之后，数据库的执行过程可能就变了。因此执行时间或者效率会受到很大影响。
想进大厂，mysql不会那可不行，来接受mysql面试挑战吧，看看你能坚持到哪里？
Clickhouse 是一个高性能且开源的数据库管理系统，主要用于在线分析处理 (OLAP) 业务。它采用列式存储结构，可使用 SQL 语句实时生成数据分析报告，另外它还支持索引，分布式查询以及近似计算等特性，凭借其优异的表现，ClickHouse 在各大互联网公司均有广泛地应用。
增加字段相信大家应该都不陌生，随手就可以写出来，给 MySQL 一张表加字段执行如下 sql 就可以了：
中台战略主要都是指通过「小前台，大中台」的架构方式，降低试错成本，加快响应速度，从而真正做到「降本增效」。
当然了实际工作中是基本不会出现这种情况的， 假设真的取了100万数据， 无论是MySQL内存缓冲区的占用，还是网络带宽的消耗都是巨大的。
索引合并是MySQL查询优化器在处理复杂查询条件时使用的一种技术。简单来说，当WHERE子句中有多个条件，并且每个条件都可以利用不同的索引时，优化器会考虑将这些索引的扫描结果合并，从而得到最终的结果集。
–check-column：用来指定一些列，这些列在导入时候检查是否被作为增量数据；
关于Clickhouse的索引的查询过程，我们先手来了解几个概念，MarkRange：在ClickHouse中是用于定义标记区间的对象。index_granularity：标记多个小的区间数据组成的粒度。MergeTree按照index_granularity的间隔粒度，将一段完整的数据划分成了多个小的间隔数据段，一个具体的数据段即是一个MarkRange。MarkRange与索引编号对应，使用start和end两个属性表示其区间范围。通过与start及end对应的索引编号的取值，即能够得到它所对应的数值区间。而数值区间表示了此MarkRange包含的数据范围。
1.库名、表名、字段名必须使用小写字母，并采用下划线分割。 a)MySQL有配置参数lower_case_table_names，不可动态更改，Linux系统默认为 0，即库表名以实际情况存储，大小写敏感。如果是1，以小写存储，大小写不敏感。如果是2，以实际情况存储，但以小写比较。 b)如果大小写混合使用，可能存在abc，Abc，ABC等多个表共存，容易导致混乱。 c)字段名显示区分大小写，但实际使⽤用不区分，即不可以建立两个名字一样但大小写不一样的字段。 d)为了统一规范， 库名、表名、字段名使用小写字母。
mysql 建立联合索引后，是按最左匹配原则来筛选记录的，即检索数据是从联合索引的第一个字段来筛选的。如果 where 里的条件只有第二个字段，那么将无法应用到索引。
利用MySQL提供的自动增长功能来自动生成主键的值，防止插入的值重复导致插入失败。自动增长功能通过auto_increment来实现，基本语法格式如下：
一个好的web应用，最重要的一点是有着优秀的访问性能。数据库MySQL是web应用的组成部分，也是决定其性能的重要部分。所以提升MySQL的性能至关重要。
与其他 DBMS 一样，MySQL 有一个具体管理和处理数据的内部引擎。在你使用CREATE TABLE 语句时，该引擎具体创建表，而在你使用 SELECT 语句或进行其他数据库处理时，该引擎在内部处理你的请求。多数时候，此引擎都隐藏在 DBMS 内，不需要过多关注它。但 MySQL 与其他 DBMS 不一样，它具有多种引擎。它打包多个引擎，这些引擎都隐藏在MySQL服务器内，全都能执行 CREATE TABLE 和 SELECT 等命令。为什么要发行多种引擎呢？因为它们具有各自不同的功能和特性，为不同的任务选择正确的引擎能获得良好的功能和灵活性。
我们遇到的最容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要（顺便说明，本节内容适用于B-Tree索引；哈希或者其他类型的索引并不会像B-Tree索引一样按顺序存储数据）。 在一个多列B-Tree索引中，索引列的顺序意味着索引首先按照最左列进行排序，其次是第二列，等等。所以，索引可以按照升序或者降序进行扫描，以满足精确符合列顺序的ORDER BY、GROUP BY和DISTINCT等子句的查询需求。 所以多列索引的顺序至关重要。在“三星索引”系统中，列顺序也决定了一个索引是否能够成为一个真正的“三星索引”。 对于如何选择索引的列顺序有一个经验法则：将选择性最高的列放到索引最前列。这个建议有用吗？在某些场景可能有帮助，但通常不如避免随机IO和排序那么重要，考虑问题需要更全面（场景不同则选择不同，没有一个放之四海皆准的法则。这里只是说明，这个经验法则可能没有你想象的重要）。 当不需要考虑排序和分组时，将选择性最高的列放在前面通常是很好的。这时候索引的作用只是用于优化WHERE条件的查找。在这种情况下，这样设计的索引确实能够最快地过滤出需要的行，对于WHERE子句中只使用了索引部分前缀列的查询来说选择性也更高。然而，性能不只是依赖于所有索引列的选择性(整体基数)，也和查询条件的具体值有关，也就是和值的分布有关。这和选择前缀的长度需要考虑的地方一样。可能需要根据那些运行频率最高的查询来调整索引列的顺序，让这种情况下索引的选择性最高。
MySQL偶尔会出现OOM（内存溢出）现象,导致MySQl服务重启，以下哪种方式能有效缓解OOM的情况发生（）
B Tree 指的是 Balance Tree，也就是平衡树。平衡树是一颗查找树，并且所有叶子节点位于同一层。
实践是检验真理的唯一途径，本篇只是站在索引使用的全局来定位的，你只需要通读全篇并结合具体的例子，或回忆以往使用过的地方，对整体有个全面认识，并理解索引是如何工作的，就可以了。在后续使用索引，或者优化索引时，可以从这些方面出发，进一步来加深对索引正确高效的使用。
由于昨天是用了之前配置了主从的机器去测试，各种失败，最后不得不使用两个新建的虚拟机去测试，正好模拟新建一个环境，我就完完整整的搭建一遍~ 需求： 在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用mysql主从方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加mysql入口，增加高可用。不过多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。
前言：在当前的数据分析岗位中，多数人在做着SQL-Boy\SQL-Girl的工作，在数据分析面试中，SQL是必不可少的一环，对于SQL不仅有常见函数用法的考察，更多时候面试官喜欢出一些编程类题目，本文我们来了解一下那些典型的SQL面试题。(文中的问题均以MySQL为例)
相信这内连接，左连接什么的大家都比较熟悉了，当然还有左外连接什么的，基本用不上我就不贴出来了。这图只是让大家回忆一下，各种连接查询。 然后要告诉大家的是，需要根据查询的情况，想好使用哪种连接方式效率更高。
我们都知道，从5.7版本开始，MySQL 支持 RFC7159定义的原生JSON数据类型，该类型支持对JSON文档中的数据的有效访问。关于MySQL 8.0 JSON数据类型，后面准备通过一个系列的文章来进行详细的介绍，这样方便大家对MySQL中JSON数据类型的使用有更好的了解；
今天跟大家聊一聊MySQL的事务隔离，并通过一些实验做了些总结。光说不练，假把式，没有经过实践就没有话语权。
GIthub上有两个Druid。其中一个是阿里的数据库连接池，另一个是列式存储的分布式数据存储系统。我曾经一度认为是一个东西，本文介绍后一种Druid。
本文主要参考官网的优化 https://dev.mysql.com/doc/refman/5.7/en/optimization.html
最近，关于电信联通合并的传闻此起彼伏，牵动着很多人的神经，也引起了行业内外的广泛关注。
前言：当业务数据达到一定量级(比如：mysql单表记录量>1千万)后，通常会考虑“分库分表”将数据分散到不同的库或表中，这样可以大大提高读/写性能。但是问题来了，对于 select * from table limit offset , pagesize 这种分页方式，原来一条语句就可以简单搞定的事情会变得很复杂，本文将与大家一起探讨分库分表后”分页”面临的新问题。
MySQL 支持由 RFC 7159 所定义的原生 JSON 数据类型，通过该类型能够有效访问 JSON（JavaScript 对象表示法）文档中的数据。与将 JSON 格式字符串存储在字符串列中相比，JSON 数据类型提供了以下优点：
但是，MySQL实际执行查询的顺序与书写顺序不同。MySQL优化器会根据内部算法和数据统计信息来决定最佳的执行顺序。以下是MySQL查询语句各个子句的实际执行顺序：
小编们最近参加了数据城堡举办的“大学生助学金精准资助预测”比赛，分组第19名的成绩进入了复赛，很激动有木有！在上一篇文章中，小编主要介绍了pandas中使用drop_duplicates()方法去除重复数据。本篇，小编文文将带你探讨pandas在数据合并的应用。 1 上期回顾 首先，小编带你回顾一下drop_duplicates()方法的使用，我们定义一个DataFrame如下： df=pd.DataFrame({'id':[1,1,2],'value':[5,10,12]}) print (df) 输出如
NSNotification是方便NSNotificationCenter广播到其他对象时的封装对象，简单讲即通知中心对通知调度表中的对象广播时发送NSNotification对象。
前段时间在跟其他公司DBA交流时谈到了mysql跟PG之间在多表关联查询上的一些区别，相比之下mysql只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)，而PG是都支持的，而且mysql是往简单化方向去设计的，如果多个表关联查询（超过3张表）效率上是比不上PG的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
