小编Ric*_*mes的帖子

我有一个busy MySQL Server查询

SELECT  sys_sess_state, index_state, timeout_lvl, last_queued_dt,
        last_polled_wait_dt, create_id, create_dt, modify_id,
        modify_dt
    FROM  PQR_AM_SYSTEM_SESSION
    WHERE  (pqr_sess_id=592885621) FOR UPDATE  

哪里pqr_sess_id是Primary Key在表中。

当我独立执行查询时，它正在完成，0.00 secs,但我多次观察到挂起的查询是带有状态统计信息的进程列表。

可能是什么问题，我在慢日志中发现此查询的计数超过 10K 次。

mysql> show full processlist;
+------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Id   | User            | Host                | db        | Command | Time | State                       | Info                                                                                                                                                                                                                                                                                                         |
+------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 2899 | root            | 192.168.9.217:49340 | abdulrony | Query   |   58 | statistics                  | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, …

我有以下查询（为简洁起见已删除），其目的是创建w8用于对结果进行排序的值：

SELECT elements.id, [ ... ],
(SELECT 
    COALESCE(craft_w8_a.weight, 0) + COALESCE(SUM(craft_w8_b.weight), 0) 
    FROM `craft_w8` `craft_w8_a`
    LEFT JOIN `craft_w8` `craft_w8_b` 
        ON craft_w8_b.elementId
        IN ( SELECT targetId FROM `craft_relations`
                WHERE fieldId IN (15, 16)
                  AND sourceId = elements.id)
    WHERE craft_w8_a.elementId = elements.id
) as w8
FROM `craft_elements` `elements`
[ ... ]
GROUP BY `elements`.`id`
ORDER BY `w8` DESC, `name` ASC LIMIT 100

我遇到的问题是第二个嵌套子查询（左连接中的那个）无法elements.id从初始选择中找到该列。

从我发现在 SQL 中搜索只传递一级深度的值，我一直无法找到合适的解决方法。

是否可以强制 SQL 传递比一级更深的值？或者有没有办法修改查询以不使用另一个子查询，但仍然得到相同的结果？

对不起，如果我做任何愚蠢的事情或遗漏了任何明显的东西，SQL 不是我的强项！

我们即将将数据库服务器复制到不同物理位置的多个从属服务器中。

为我们进行复制的公司要求在我们的一个表上为他们提供一条 sql select 语句，以检查延迟和延迟，例如

SELECT id FROM table1 ORDER BY id DESC LIMIT 1

检查多个实例之间的滞后是一种常见的做法吗？

先感谢您。

现在有两种方法可以在 MySQL 中构建表的索引：

1. 首先创建表结构，然后导入数据并添加索引。
2. 创建带有索引的表结构，然后导入数据。

在第一个过程中，我们将拥有连续的数据（所有字段）页面，然后是索引页面。所以当我们使用索引查询时，MySQL 必须首先加载索引页并找出匹配的键，并且必须在数据页上查找那些主键。为此，它必须再次加载数据页以获取数据。当我们有更大的索引扫描时这很有用，因为我们所有的索引都是连续加载的。

在索引创建的第二种方式中，过滤后的索引页很可能包含与它们同时创建的靠近它的数据页。所以我想小范围扫描的查找速度会更快。

我的理解正确吗？

更新：

我应该在第一种导入数据的方式中提到“PRIMARY KEY 已启用”（自动递增 id 列）。因此，不会生成内部 rowid，并且由于我们不打算添加 PRIMARY KEY，因此会保存大量 IO。

正如您所指出的，当我们使用第二种方法导入数据时会出现碎片。

考虑到我的要求是更大范围的扫描（扫描~100M 行），我想我会采用第一种导入数据的方式。

6 月 8 日 11:30 更新

CREATE TABLE `table_dummy` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `column1` bigint(20) DEFAULT NULL,
  `column2` bigint(20) DEFAULT NULL,
  `column3` bigint(20) DEFAULT NULL,
  `created_at` datetime DEFAULT NULL,
  `column4` tinyint(1) DEFAULT NULL,
  `column5` tinyint(4) DEFAULT NULL,
  `column6` bigint(20) DEFAULT NULL,
  `column6_created_at` datetime DEFAULT NULL,
  `column7` int(11) DEFAULT NULL,
  `column8` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`id`), …

假设我有一个类似的查询：

SELECT *
FROM table_a
    JOIN table_b USING (id)
WHERE table_b.column = 1

我有一个索引id和一个索引，column但我经常添加一个复合索引，两者都可以提高这样的查询效率。我的问题是关于索引中列的顺序。通过反复试验，我发现有时 DBMS 更喜欢连接索引，有时它更喜欢WHERE索引。

在上面的查询中，是否有一个硬性、快速的规则可以让我知道哪个键顺序最有效？

通常我只添加两个索引，运行EXPLAIN查询并检查哪个是首选的，然后删除另一个。但是这个过程感觉可以通过更好地理解确定索引顺序所涉及的逻辑来改进。

我看到以下同时使用 DISTINCT 和 GROUP BY 的 MySQL 查询：

SELECT  DISTINCT user_id, post_id, post_content
    FROM  some_table
    GROUP BY  post_id, user_id
    HAVING  post_content LIKE '%abc%';

这是一个与查询一起使用的场景：每个用户都有一个唯一的 id，user_id，并且可以发表多个由唯一 id 标识的帖子post_id。每个帖子都会包含一些文本。

我发现这令人困惑（来自 Oracle DB 之后）并有以下问题：

1. 使用GROUP BY而不做任何聚合是什么意思？
2. 在SELECTvs in中切换列的顺序有什么意义GROUP BY？
3. 从 省略第三列是什么意思GROUP BY？
4. 为什么DISTINCT与 一起使用GROUP BY？在对最终结果或之前完成所有分组之后，是否运行不同的操作？

我在创建带有生日字段的用户表时犯了一个错误，我没有放置 DATE 数据类型，而是放置了一个 VARCHAR！

所以现在我的用户表看起来像这样：

CREATE TABLE IF NOT EXISTS users 
(
  id INT    UNSIGNED NOT NULL,
  birthdate VARCHAR (200) NOT NULL,

  PRIMARY KEY (id)
) DEFAULT CHARSET=utf8;

它填充如下（样本）：

INSERT INTO users (id, birthdate) VALUES
  (1,'1991-01-23'),
  (2,'yyyy-01-23'),
  (3,'1991-mm-23'),
  (4,'1991-01-dd'),
  (5,''),
  (6,'1991-01-d3'),
  (7,'1983-05-23'),
  (8,'1991-0m-23'),
  (9,'19yy-01-23'),
  (10,'y991-01-23');

现在我想将每个不正确的生日更新为 NULL，或者设置一个默认值，如 2020-01-01。在这里查看我的 sqlfiddle 。

我有一个查询，我尝试插入一条记录并准备更新以防记录存在。

问题是我想知道，一旦执行查询，该操作是更新还是插入。

任何想法？

[免责声明]我对数据库并不陌生，但对复制和集群完全是新手......

您可能知道 Mysql 提供了一项新功能：MySql 组复制。

有人可以向我解释这种架构和集群之间的根本区别吗？任何主要功能仅存在于两者之一吗？节点容错 ? 是否有能力回到现场状态？欢迎提出任何建议...

谢谢

我的 sql 数据库中有 3 个表：

Table Room

roomnumber   roomtype    
  1           DeluxeRoom           
  2           DeluxeRoom  
  3           DeluxeRoom
  100         StandardRoom           
  101         StandardRoom  
  102         StandardRoom

Room 是一张存储房间及其类型的表。

Table Reservation

reservationid  checkin       checkout
  1           2017-01-01     2017-01-03
  2           2017-01-10     2017-01-20
  3           2017-02-05     2017-02-08

预订是用户进行预订的表。

Table RoomReserve

reservationid    roomnumber
 1                 1
 2                 100
 2                 101
 3                 1
 3                 2
 3                 3

在 RoomReserve 中，对于每个 bookingid，我可以输入多个 roomnumber 值。如果入住和退房日期不同，我还可以为不同的预订 ID 输入相同的房间号。

当用户想要预订房间时，我试图进行查询来计算可用房间，但我得到的结果是错误的。

这是我正在尝试的代码：

SELECT  COUNT(roomnumber)
    FROM  room
    WHERE  roomtype='DeluxeRoom'
      AND  roomnumber NOT IN (
        SELECT  *
            FROM  roomreserve r,reservation …