21 天前 / sjf0115
作者：潘彼得 本文为「心中有数」CDA 征文作品 无论是产品经理、产品运营还是数据分析师，在评估一个产品的用户使用情况时肯定离不开留存率、忠诚度等观测指标。这些指标可以反映用户对于产品的粘性、产品用户价值质量的高低，及时了解用户留存、流失趋势，有助于帮助产品做更好的功能迭代，也有助于运营及时进程运营策略的调整，比如：当新用户留存率低的时候，是不是需要调整新用户的活动策略，或者当老用户留存率低的时候，是不是某个产品功能的问题，或者活动对老用户不友好而导致流失等等…… 今天，就给大家分享下如何用 SQL 实现留存率的计算...
28 天前 / 臻大虾
求关注 求转发 1、sql 注入是什么 sql 注入就是用户通过输入的参数，拼接到原先的 sql 中，成为 sql 的一部分，从而影响 sql 的功能和执行结果 2、sql 注入破坏力 - 小兵破坏力比如原先 sql 如下 select*fromuserwherename='用户名'andpassword='密码'; 用户输入 name：臻大虾'--'注释 password：密码 那最终的结果猜猜是什么？ select*fromuserwherename='臻大虾'--'注释'andpassword='密码'; 两个 -- 代表注释，所以这条 sql 只需要输入用户名，就可以获取用户信息，跳过了密码的校验 - boss 破坏力来个厉害的...
61 天前 / sjf0115
原文发布时间：2017 年 越来越多的公司采用流处理，并将现有的批处理应用程序迁移到流处理，或者采用流处理实现的解决方案。其中许多应用程序专注于流数据分析，分析的数据流来自各种数据源，例如，数据库事务、点击、传感器测量或 IoT 设备等。 Apache Flink 非常适合流分析应用程序，因为它支持事件时间语义、有状态的 Exactly-Once 处理语义，并同时实现了高吞吐量和低延迟。由于这些特性，Flink 能够近乎实时地从大量输入流中计算出准确以及确定性的结果，并能在出现故障时提供 Exactly-Once 处理语义。
89 天前 / 大数据架构师
Apache ShardingSphere 5.0.0-beta 深度解析的第一篇文章和大家一起重温了 ShardingSphere 的内核原理，并详细阐述了此版本在内核层面，特别是 SQL 能力方面的优化和提升。强大稳定的内核是 ShardingSphere 持续发展的基础，与此同时，ShardingSphere 在研发分布式数据库生态特性上也在努力摸索。本次 5.0.0-beta 版本发布的 DistSQL，用于搭配整个 ShardingSphere 分布式数据库体系，在提供更标准化的分布式数据库管理方式的同时，兼具灵活、便捷和优雅的特性。
90 天前 / BloomingRose
今天和大家聊一个常见的问题：慢 SQL。 通过本文你将了解到以下内容： 慢 SQL 的危害 SQL 语句的执行过程存储引擎和索引的那些事儿慢 SQL 解决之道后续均以 MySQL 默认存储引擎 InnoDB 为例进行展开，话不多说，开搞！ 1.慢 SQL 的危害慢 SQL，就是跑得很慢的 SQL 语句，你可能会问慢 SQL 会有啥问题吗？ 试想一个场景： 大白和小黑端午出去玩，机票太贵于是买了高铁，火车站的人真是乌央乌央的。 马上检票了，大白和小黑准备去厕所清理下库存，坑位不多，排队的人还真不少。
94 天前 / HelloGitHub
原文地址：SQL queries don't start with SELECT 原文作者：Julia Evans（已授权） 译者 & 校正：HelloGitHub- 小熊熊 & 卤蛋 日常使用中写 SQL 查询命令都是以 SELECT 开始的（注意：本文仅探讨 SELECT 查询，不涵盖 insert 或其他 SQL 命令）。 昨天我想到一个问题：可以用 WHERE、HAVING 或者其他方式来过滤窗口函数执行结果吗？ 经过一番探索，我得出的最终结论是否定的，因为窗口函数必须在 WHERE 和 GROUP BY 之后才能运行。
109 天前 / 微观技术
大家好，我是 Tom 哥~ 我们都知道，业务开发涉及到数据库的 SQL 操作时，一定要 review 是否命中索引。否则，会走 全表扫描，如果表数据量很大时，会慢的要死。 假如命中了索引呢？是不是就不会有慢查询？ 殊不知，我们习以为常的常识有时也会误导我们！ 人生好难！ 聊这个话题，要有一定技术基础，需了解 B+ 树的存储结构 如果不是很清楚的话，先看下之前一篇文章，有详细介绍 面试题：mysql 一棵 B+ 树可以存多少条数据？ 1、工作准备：建表，造数据 首先创建一张 user 表，并创建一个 id 的主键索引，和一个 user_name 的普通索引。
115 天前 / sjf0115
摘要：本文由社区志愿者陈政羽整理，Apache Flink 社区在 5 月份发布了 1.13 版本，带来了很多新的变化。文章整理自徐榜江 ( 雪尽)5 月 22 日在北京的 Flink Meetup 分享的《深入解读 Flink SQL 1.13》，内容包括： Flink SQL 1.13 概览核心 feature 解读重要改进解读 FlinkSQL 1.14未来规划 总结 Tips：点击文末「阅读原文」即可查看更多技术干货～ GitHub 地址 https://github.com/apache/flink 欢迎大家给Flink点赞送 star~ 一、Flink SQL 1.13 概览 Flink 1.13 是一个社区大版本，解决的 issue 在 1000 个以上，通过上图我们可以看到...
125 天前 / 码匠赵铁柱
今天和大家聊一个常见的问题：慢 SQL。 通过本文你将了解到以下内容： 慢 SQL 的危害 SQL 语句的执行过程存储引擎和索引的那些事儿慢 SQL 解决之道后续均以 MySQL 默认存储引擎 InnoDB 为例进行展开，话不多说，开搞！ 1.慢 SQL 的危害慢 SQL，就是跑得很慢的 SQL 语句，你可能会问慢 SQL 会有啥问题吗？ 试想一个场景： 大白和小黑端午出去玩，机票太贵于是买了高铁，火车站的人真是乌央乌央的。 马上检票了，大白和小黑准备去厕所清理下库存，坑位不多，排队的人还真不少。
125 天前 / Yourtion
SQL（Structured Query Language）作为一种领域语言（编程语言），最早用于关系型数据库，方便管理结构化数据；SQL 由多种不同的类型的语言组成，包括数据定义语言，数据控制语言、数据操作语言；各数据库产品都有不同的声明和实现；用户可以很方便的使用 SQL 操作数据，数据库系统中的词法语法分析器负责分析和理解 SQL 文本的含义，包括词法分析、语法分析、语义分析 3 部分。经过词法语法分析器生成 AST（Abstract Syntax Tree），会被优化器处理生成生成执行计划，再由执行引擎执行，下图以 MySQL 架构为例展示词法语法分析器所处的位置。
129 天前 / reesunhuang
“经常看到由于慢查询引起生产故障的文章，在高并发的业务场景，一条慢 SQL 可能导致上百万甚至更高的资损。开发带来的慢 SQL 主要来源于三个方面：”已有业务运行中的 SQL、新增业务增加的 SQL、日常业务查询的 SQL“。针对已有业务运行中的 SQL 可以通过细化的监控、慢查询分析、事物分析等手段防止它们对业务带来影响；针对新上线的 SQL 可以通过给开发提管控要求，平台对 bad SQL 进行自动预判；这篇聊聊如何保证日常业务查询 SQL 对生产的影响，即构建稳定健壮的统一查询平台。
129 天前 / HueiFeng
源宝导读：在企业建设信息化的过程中，客户通常会使用一些数仓工具来构建数据资产，随着用户的要求越来越高，传统的 ETL 技术已经无法满足客户的实时性诉求，本文将分享“天际 - 数据平台”如何基于 SQL Server 来实现数仓数据的实时更新。一、实现思路为了提升数据的时效性，最简单的方法是将 ETL 的频率设置为每分钟一次或更短，以达到数据及时更新的目的。很显然，这种方案会给服务器造成很大的压力，有些 ETL 的执行时长甚至超过了调度周期，并不是一个可行的方案。
130 天前 / 逗逗
对于我们数据仓库工程师来说，写 SQL 就是家常便饭。但 SQL 如果写的不好，就很容易引起性能问题。那我们如何去定位我们的 SQL 会不会有性能问题呢？ 在 Spark SQL 中，其实也不止 Spark SQL，所有的 SQL 执行引擎都会提供执行计划给我们，让我们能直观看到我们的 SQL 到底是如何被执行的，是否按照我们的预期执行，然后我们可以针对性的进行优化。 但是，对于不熟悉执行计划的人来说，特别是没有很深入用过 Spark Core 的人来说，执行计划看起来可能特别难懂。 在这篇文章中，我会详细介绍执行计划中的每个点。
132 天前 / 尹千觞
Spark SQL 的 Catalyst ，这部分真的很有意思，值得去仔细研究一番，今天先来说说 Spark 的一些扩展机制吧，上一次写 Spark，对其 SQL 的解析进行了一定的魔改，今天我们按套路来，使用砖厂为我们提供的机制，来扩展 Spark... 首先我们先来了解一下 Spark SQL 的整体执行流程，输入的查询先被解析成未关联元数据的逻辑计划，然后根据元数据和解析规则，生成逻辑计划，再经过优化规则，形成优化过的逻辑计划（RBO），将逻辑计划转换成物理计划在经过代价模型（CBO），输出真正的物理执行计划。 我们今天举三个扩展的例子，来进行说明。
137 天前 / vivo互联网技术
作者：vivo 互联网服务器团队 -Li Lei 一、背景 1.1 传统 Mybatis 的弊端 1.1.1 场景描述 假设有两张表：一张商品表、一张订单表，具体表的字段如下： 现有如下需求： 分别根据 id 查询商品表和订单表所有信息根据支付状态和通知状态查询订单表信息对订单表增加一个订单状态，根据订单状态查询订单信息 1.1.2 需求 需求 a：根据 id 查询商品表：@Select(" SELECT p.id ,p.name ,p.picture ,p.type ,p.price, p.type, p.time FROM product p where id = #{id} ")List getProductsBYId(@Param("id") Integer id); 根据 id 查询订单表所有信息：@Se...