标签: database-optimization

晚间,

我正在经历漫长的过程,将数据从受到重视的,已有15年历史的只读数据格式导入MySQL,以便从中构建一些较小的统计表.

我之前构建的最大的表是(我认为)3200万行,但我没想到它会变得那么大并且真的让MySQL变得紧张.

该表将如下所示:

surname    name    year    rel    bco    bplace    rco    rplace
Jones      David   1812    head   Lond   Soho      Shop   Shewsbury

所以,小的int和varchars.

任何人都可以提供有关如何尽快使其工作的建议吗？任何coulmns上的索引是否有帮助,或者它们只会减慢查询速度.

每列中的大部分数据将重复多次.某些字段的可能值不超过100个.

我将查询表的主要栏目是:姓氏,名字,rco,rplace.

我有下表存储有关图像的数据:

images
 - id (int)
 - sample_1_1 (int)
 - sample_1_2 (int)
 - sample_1_3 (int)
 - sample_2_1 (int)
 - sample_2_2 (int)
 - sample_2_3 (int)
 - ... # Up until sample_25_3

任务是计算收集的数据之间的距离.目前,我正在使用75维(正确的,3*25 = 75)欧几里德距离计算编程为数据库中的存储过程:

CREATE DEFINER=`root`@`localhost`
FUNCTION `distanceBetween`(compareId INT, toId INT) RETURNS double
    READS SQL DATA
    DETERMINISTIC
BEGIN
 DECLARE distance DOUBLE;
SELECT euclidDistance(
 i1.sample_1_1, i1.sample_1_2, i1.sample_1_3,
 i2.sample_1_1, i2.sample_1_2, i2.sample_1_3,
 ...
 ) INTO distance
FROM images i1, (SELECT * FROM images WHERE id = toId) i2
WHERE i1.id = compareId;
RETURN distance;
END …

我有一个查询正在两个等效的数据库上运行，但托管在单独的 MS SQL 2005 服务器上。我想测量两台服务器上的查询时间，因此尝试了以下方法：

SET STATISTICS TIME ON
GO
SELECT TOP 10000 *
  FROM table
GO
SET STATISTICS TIME OFF;
GO

并得到以下结果：

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 2 ms.

(10000 row(s) affected)

SQL Server Execution Times:
   CPU time = 16 ms,  elapsed time = 8143 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

我的问题是，SQL Server 执行时间是什么意思？是仅在数据库中执行查询，还是执行查询（包括将数据传输回运行 SQL Server Management Studio 的客户端）？ …

我正在对数据库中的所有行运行批处理操作.这包括选择每个模型并对其做一些事情.将它分成块并将其分块大块是有意义的.

我目前正在使用Paginator,因为它很方便.这意味着我需要对值进行排序,以便可以按顺序分页.这确实会生成带有order和limit子句的SQL语句,对于每个块我认为Postgres可能会对整个表进行排序(尽管我不能声称对内部有任何了解).我所知道的是,数据库的CPU大约占50%,而且我觉得这样做太高了select.

以RDMBS/CPU友好的方式迭代整个表的最佳方法是什么？

假设在批处理操作期间数据库的内容没有改变.

我有一些innoDbs只有2个int列,它们是其他表的主键的外键.

例如,一个表是user_items,它有2列,userId,itemId,用户和项目表的外键,如果更新或删除则设置为级联.

我应该在这些表中添加第3列并将其作为主键,还是在性能或任何其他好处方面,它现在的方式更好？

虽然这听起来像是一个愚蠢的问题，但有时有必要显示页码（以及最后一页）。在基于游标的分页中计算总行数并计算页码（通过提供页面查询以返回特定页面）的最佳方法是什么？所有这些都可以在单个查询中实现吗？

流行的例子：谷歌使用基于光标的分页和行数在谷歌搜索中显示页码。

我有一个具有多个模式的 Postgres 数据库。我正在尝试使用最佳数据类型来优化我的数据库表。更多时候我以错误结束

无法更改视图使用的列的类型

使用查询时 alter table schema.tbl_name alter column column_name type varchar(5) using column_name::varchar(5);

有什么方法（函数）可以列出与表相关的所有视图吗？

我想加快对包含大量旧数据的大表的查询速度。

我有一个名为post的表，其中包含日期列created_at。该表包含超过约 3100 万行和超过 30 天的约 3000 万行。

事实上，我想要这个：

• 将超过 30 天的数据移动到post_archive表中或创建分区表。
• 当创建的列中的值超过 30 天时，应将该行移至post_archive表或分区表。

PostgresSQL 11.15有详细具体的解决方案吗？

我的想法：

• 解决方案1.用任何语言（例如JavaScript）创建一个cron脚本并每天运行它以将post表中的数据复制到post_archive中，然后从post表中删除数据
• 解决方案 2. 创建一个 Postgres 函数，将数据从post表复制到分区表中，并创建一个每天调用该函数的 cron 作业

谢谢

我这里有两张桌子:

ITEMS
ID| DETAILS| .....| OWNER

USERS:
ID| NAME|....

哪里 ITEMS.OWNER = USERS.ID

我列出了各自所有者名称的项目.为此,我可以用两个表的联接我也可以选择通过他们做一个SQL查询的所有项目和循环检索的元组的是itmes所有者.这就像:

1个带有JOIN的sql与1x20单个表的sql查询

在速度方面哪个更好？谢谢

在面对mysql查询的加载时间问题之后,我现在正在寻找计算行数的最佳方法.我愚蠢地使用mysql_num_rows()函数来做到这一点,现在意识到这是一个最糟糕的方法.我实际上正在制作一个用PHP制作页面的分页.我找到了几种计算行数的方法.但我正在寻找更快的方法来计算它.

表类型是MyISAM

所以现在的问题是

哪个是最好的,也更快计算 -

1. `SELECT count(*) FROM 'table_name'`

2. `SELECT TABLE_ROWS
FROM INFORMATION_SCHEMA.TABLES WHERE table_schema =  'database_name'
AND table_name LIKE  'table_name'`

3. `SHOW TABLE STATUS LIKE 'table_name'`

4. `SELECT FOUND_ROWS()`

如果还有其他更好的方法,请告诉我们.如果可能的话,请描述答案 - 为什么它最好,更快.所以我可以理解并可以根据我的要求使用该方法.

谢谢.

我在mysql中有一个用户表，其中包含所有用户数据（名字，姓氏，地址等）

但是，我应该将身份验证详细信息存储在另一个表（用户名，密码）中，并通过用户ID链接两个表吗？

这有什么意义吗？

它更安全吗？

还是只是增加额外的编码？

我的架构是

CREATE TABLE a (
  id     BIGINT PRIMARY KEY,
  dt     TIMESTAMP NOT NULL
);

我在dt上创建了一个索引:

CREATE INDEX a_dt_index ON a (dt);

当我使用像这样的查询时,索引工作正常

SELECT *
FROM a
WHERE dt >= '2008-12-30' AND dt < '2008-12-31';

但是,当我使用date()函数时,不使用索引.

SELECT *
FROM a
WHERE date(dt) = '2008-12-30'

在我看来,这两个查询在语义上是相同的,那么为什么索引没有被使用？为什么我必须创建一个显式的date()索引？

CREATE INDEX a_date_index ON a (date(dt));

我有一个大小为1677,25 MB的SQL Server数据库.这是我详细的数据库大小信息:

数据库大小:1677.25 MB
未分配空间:343.09 MB

保留:24488 KB数据:18560 KB索引大小:2632 KB未使用:3296 KB行数:74410

所以,你可以看到它并不是那么大的数据库.问题是,日志.

日志文件的大小为:1.311 GB

我该如何清理旧日志？好吧也许过去3个月很重要,但1.3 GB确实是一个重要的尺寸.