相关疑难解决方法(0)

Mysql int vs varchar 作为主键(InnoDB 存储引擎?

我正在构建一个 Web 应用程序(项目管理系统),并且在性能方面我一直对此感到疑惑。

我有一个问题表,里面有 12 个外键链接到各种其他表。其中,我需要加入其中的 8 个以从其他表中获取标题字段,以便记录在 Web 应用程序中有意义,但这意味着进行 8 个连接,这似乎非常多,尤其是因为我只是在拉入每个连接有 1 个字段。

现在我还被告知要使用自动递增的主键(除非分片是一个问题,在这种情况下我应该使用 GUID)出于永久性原因,但是使用 varchar(最大长度 32)性能有多糟糕?我的意思是这些表中的大多数可能不会有很多记录(其中大多数应该低于 20)。此外,如果我使用标题作为主键,我将不必在 95% 的时间内进行连接,因此对于 95% 的 sql,我什至会发生任何性能下降(我认为)。我能想到的唯一缺点是我的磁盘空间使用量会更高(但一天下来真的很重要)。

我使用查找表来代替枚举的原因是因为我需要最终用户通过应用程序本身来配置所有这些值。

使用 varchar 作为表的主键的缺点是什么,除非有很多记录?

更新 - 一些测试

所以我决定对这些东西做一些基本的测试。我有 100000 条记录,这些是基本查询:

基本 VARCHAR FK 查询

SELECT i.id, i.key, i.title, i.reporterUserUsername, i.assignedUserUsername, i.projectTitle, 
i.ProjectComponentTitle, i.affectedProjectVersionTitle, i.originalFixedProjectVersionTitle, 
i.fixedProjectVersionTitle, i.durationEstimate, i.storyPoints, i.dueDate, 
i.issueSecurityLevelId, i.creatorUserUsername, i.createdTimestamp, 
i.updatedTimestamp, i.issueTypeId, i.issueStatusId
FROM ProjectManagement.Issues i
Run Code Online (Sandbox Code Playgroud)

基础 INT FK 查询

SELECT i.id, i.key, i.title, ru.username as reporterUserUsername, 
au.username as assignedUserUsername, p.title as projectTitle, 
pc.title as …
Run Code Online (Sandbox Code Playgroud)

mysql innodb performance primary-key

16
推荐指数
3
解决办法
3万
查看次数

如何恢复文件被移动的 InnoDB 表

所以我有一个在复制流上设置的测试数据库服务器。在名称上出现了一个优化,它迅速填满了 slaves 数据目录上的空间。Mysql 尽职尽责地等待更多空间。

这个 datadir 是一个文件系统,只用作 mysql 的 datadir,所以没有其他东西可以释放。

我有一个 4 g innodb 测试表,它不是复制流的一部分,所以我想我会尝试一些东西来看看它是否有效,作为一个测试环境,如果事情出现严重错误,我并不太担心。

这是我采取的步骤

  1. 冲洗了我正要移动的桌子
  2. 在它上面放置了一个读锁(即使没有写入它并且它不在复制流中)
  3. 将 .frm 和 .ibd 复制到带有一些空闲空间的文件系统
  4. 解锁了桌子
  5. 截断该表 - 这为优化完成释放了足够的空间,复制开始再次开始。
  6. 停止从属/关闭 mysql
  7. 将文件从 tmp 复制回数据目录
  8. 重启mysql

.err 日志中没有显示任何内容,看起来不错。我连接并使用 mydb;并查看我在展示表中弄乱的表。但是,如果我尝试

select * from testtable limit 10;
Run Code Online (Sandbox Code Playgroud)

我收到错误

ERROR 1146 (42S02): Table 'mydb.testtable' doesn't exist
Run Code Online (Sandbox Code Playgroud)

到目前为止,我可以从所有其他表中读取数据,并且复制开始备份,没有任何抱怨。

我能做些什么来从这一点上恢复过来吗?如果需要,我可以从头开始重建它,但很好奇其他人对这次冒险的总体看法。我采取的一系列步骤是否有任何结果会导致更​​完美的结果?

如果这不是一个测试服务器,我不能只是“实时运行”看看会发生什么?如果我不得不喜欢,有什么最好的方法可以暂时释放生产从站上的空间?

mysql innodb disk-space

15
推荐指数
1
解决办法
8万
查看次数

什么会导致 TRUNCATE TABLE 花费很长时间?

我正在运行带有主/从复制(1 个主,2 个从)的 MySQL5.5。

我有一个每周运行一次并截断特定表的进程。表不大,只有几千条记录。

出于某种原因,该TRUNCATE TABLE命令需要很长时间才能执行(在主机和从机上)。执行大约需要 400K 毫秒!!当它在从站上运行时,会导致它滞后于主站。在后TRUNCATE TABLE结束,一切恢复正常。

我知道其中一个从站在执行时没有收到任何读取,TRUNCATE TABLE因为它是一个专用的从站,并且从该从站读取的进程已关闭。此外,在此从属设备上,执行所需的时间相同。

这是表结构:http : //pastebin.com/qEQB4juR

关于如何加速 TRUNCATE TABLE 的任何想法?

mysql replication truncate mysql-5.5

9
推荐指数
1
解决办法
3万
查看次数