【转】MySql官方建议:Innodb表最佳实践

原文:http://dev.mysql.com/doc/refman/5.5/en/innodb-default-se.html
Best Practices for InnoDB Tables
If you have been using InnoDB for a long time, you already know about features like transactions and foreign keys. If not, read about them throughout this chapter. To make a long story short:

1) Specify a primary key for every table using the most frequently queried column or columns, or an auto-increment value if there isn't an obvious primary key.
指定主键:使用最频繁查询的一个或者多个列作为主键,如果没有,就使用自增id作为主键

2) Embrace the idea of joins, where data is pulled from multiple tables based on identical ID values from those tables. For fast join performance, define foreign keys on the join columns, and declare
those columns with the same datatype in each table. The foreign keys also propagate deletes or updates to all affected tables, and prevent insertion of data in a child table if the corresponding IDs are not present in the parent table.
拥抱join:当数据从多个表里面按照相同的ID值取出来的时候,优先使用join,可以使用外键来提高join的性能。

3) Turn off autocommit. Committing hundreds of times a second puts a cap on performance (limited by the write speed of your storage device).
关闭autocommit:每秒提交几百次会限制性能。
(译者注:业务系统建议不要关闭,否则编程比较麻烦,批量导入数据的时候可以关闭,然后定时或者定量commit)

4) Bracket sets of related changes, logical units of work, with START TRANSACTION and COMMIT statements. While you don't want to commit too often, you also don't want to issue huge batches of INSERT,
UPDATE, or DELETEstatements that run for hours without committing.
使用事务提交,避免频繁提交

5) Stop using LOCK TABLE statements. InnoDB can handle multiple sessions all reading and writing to the same table at once, without sacrificing reliability or high performance. To get exclusive
write access to a set of rows, use theSELECT ... FOR UPDATE syntax to lock just the rows you intend to update.
不要使用LOCK TABLE操作,Innodb的机制能够支持高并发操作,且不损失可靠性和性能。推荐使用SELECT....FOR UPDATE

6) Enable the innodb_file_per_table option to put the data and indexes for individual tables into separate files, instead of in a single giant system tablespace.
(This setting is required to use some of the other features, such as table compression and fast truncation.)
打开innodb_file_per_table选项

时间: 2024-11-03 14:44:27

【转】MySql官方建议:Innodb表最佳实践的相关文章

PHP最佳实践(译)

简介 PHP是一门复杂的语言,经过多年折腾,使其不同版本之间高度不一致,有时还有些bug. 每个版本都有自己独有的特性.多余和怪异之处,也很难跟踪哪个版本有哪些问题.这也就 很好理解为什么有时它会遭到那么多的厌恶. 尽管如此,如今它还是Web开发方面最流行的语言.因其悠久的历史,对于实现密码哈希和 数据库访问诸如此类的基本任务你能够找到很多教程.但问题在于,5个教程,你就很有可能 找到5种完全不同的完成任务的方式,那么哪种是"正确"的方式呢?其他方式有难以捉摸的bug 或者陷阱?确实很

是谁,把InnoDB表上的DML搞慢的?

0.导读 突然发现MySQL服务器上InnoDB表的DML线程频繁被阻塞,TPS下降比较厉害,是什么原因导致? 1.问题 我的朋友小明(又是悲催的小明),发现有个MySQL数据库最近DML明显变慢了,执行SHOW PROCESSLIST总能看到DML线程状态,TPS下降也挺厉害的,不知道什么原因. 接到小明的求助,我第一反应是,可能有几个原因: 服务器的性能不足: InnoDB buffer pool size分配不够: 表DDL设计不合理,例如没有基于索引的SQL请求,或者InnoDB表没有使

MySQL Innodb数据库性能实践——合适的表记录数

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

MySQL · 答疑解惑 · MySQL 锁问题最佳实践

前言 最近一段时间处理了较多锁的问题,包括锁等待导致业务连接堆积或超时,死锁导致业务失败等,这类问题对业务可能会造成严重的影响,没有处理经验的用户往往无从下手.下面将从整个数据库设计,开发,运维阶段介绍如何避免锁问题的发生,提供一些最佳实践供RDS的用户参考. 设计阶段 在数据库设计阶段,引擎选择和索引设计不当可能导致后期业务上线后出现较为严重的锁或者死锁问题. 1. 表引擎选择使用myisam,引发table level lock wait. 从5.5版本开始,MySQL官方就把默认引擎由my

[2016-03]MySQL · 答疑解惑 · MySQL 锁问题最佳实践

前言 最近一段时间处理了较多锁的问题,包括锁等待导致业务连接堆积或超时,死锁导致业务失败等,这类问题对业务可能会造成严重的影响,没有处理经验的用户往往无从下手.下面将从整个数据库设计,开发,运维阶段介绍如何避免锁问题的发生,提供一些最佳实践供RDS的用户参考. 设计阶段 在数据库设计阶段,引擎选择和索引设计不当可能导致后期业务上线后出现较为严重的锁或者死锁问题. 1. 表引擎选择使用myisam,引发table level lock wait. 从5.5版本开始,MySQL官方就把默认引擎由my

MySQL 的 20+ 条最佳实践_Mysql

数据库操作是当今 Web 应用程序中的主要瓶颈. 不仅是 DBA(数据库管理员)需要为各种性能问题操心,程序员为做出准确的结构化表,优化查询性能和编写更优代码,也要费尽心思. 在本文中,我列出了一些针对程序员的 MySQL 优化技术. 在我们开始学习之前,我补充一点:你可以在 Envato Market 上找到大量的 MySQL 脚本和实用程序. 1.优化查询的查询缓存 大部分MySQL服务器都有查询缓存功能.这是提高性能的最有效的方法之一,这是由数据库引擎私下处理的.当同一个查询被多次执行,结

从商用到开源:DB2迁移至MySQL的最佳实践

身处数据驱动快速变革的时代,数据库系统的选型和架构设计对于整个IT基础架构,甚至企业的发展都起到至关重要的作用.那么今天,如果您的企业需要搭建一套新的应用系统,你会选择什么数据库类型?如果当前的系统不能满足业务需求,面临系统迁移,你又会如何选择? 在2017年初,我们分享过一份国外的报告"开发人员是如何使用数据库的 ",并且进行了一次调查『中国数据库爱好者的选择和背离』,其中的一些数据展示了用户对于数据库的选择,非常具有参考价值,链接可以直接参考分析报告. 随着互联网+时代的到来,企业

MySQL · 最佳实践 · RDS 只读实例延迟分析

前言 只读实例是目前 RDS 用户实现数据读写分离的一种常见架构,用户只需要将业务中的读请求分担到只读节点上,就可以缓解主库查询压力,同时也可以把一些 OLAP 的分析查询放到另外的只读节点上,减小复杂统计查询对主库的冲击,RDS只读节点架构图如下: 由于RDS只读节点采用原生的MySQL Binlog复制技术,那么延迟必然会成为其成立之初就会存在的问题.延迟会导致只读节点与主库的数据出现不一致,进而可能造成业务上逻辑的混乱或者数据不正确. 最近也收到了很多用户关于只读实例延迟的问题反馈,下面将

RDS MySQL空间优化最佳实践

在前三期介绍了RDS for MySQL参数优化,锁问题以及延迟优化最佳实践之后,本期将介绍存储空间相关的最佳实践. 存储空间是RDS很重要的一个指标,在RDS的工单问题中,空间问题的咨询可以排在top 5,当RDS的实际使用空间超过了购买的空间后,实例就会被锁定了,这样就会导致应用无法再写入,更新数据,造成应用的报错.在RDS的控制台中可以设定空间的报警阀值,当实例空间到达报警阀值后用户就会收到报警短信,这个时候用户则需要对判断当前的空间增长是否合理.如果增长合理则需要对实例的进行弹性升级,这