mysql update语句

1、auto_increment 理解1 auto_increment是用于主键自动增长的，从1开始增长，当你把第一条记录删除时，再插入第二跳数据时，主键值是2，不是1。 例如： create table `test` ( `id` int(10) not null auto_increment, -- 表示自增列 `name` varchar(20) not null, primary key(`id`) ) 　　 auto_increment = 1; -- 表示自增起始大小-- 这样就可以创建一个表`test`,id为自增列 -- 执行语句 insert into test (`name`) values ('名字'); -- 就可以插入一行数据为: 1 '名字' 扩展资料： 在使用AUTO_INCREMENT时，应注意以下几点： 1、AUTO_INCREMENT是数据列的一种属性，只适用于整数类型数据列。 2、设置AUTO_INCREMENT属性的数据列应该是一个正数序列，所以应该把该数据列声明为UNSIGNED，这样序列的编号个可增加一倍。 3、AUTO_INCREMENT数据列必须有唯一索引，以避免序号重复(即是主键或者主键的一部分)。AUTO_INCREMENT数据列必须具备NOT NULL属性。 4、AUTO_INCREMENT数据列序号的最大值受该列的数据类型约束

Mysql中默认的是MyISAM数据引擎，可惜此引擎不支持事务处理，我们需要将默认的数据引擎改为InnoDB。 InnoDB：用于事务处理应用程序，具有众多特性，包括ACID事务支持。 启动InnoDB引擎的方法如下： 1)关闭mysql的服务 2)修改my.ini 将default-storage-engine=INNODB前的注释(#)去掉 将skip-innodb这行注释(加上#) 3)保存后重启mysql服务； InnoDB实现了以下两种类型的行锁。 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。 排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。 另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。 意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。 意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。 InnoDB行锁模式兼容性列表 如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。 意向锁是InnoDB自动加的，不需用户干预。对于UPDATE

（进入 mysql\bin 目录下） 注意在 mysql 控制台操作每句后要加分号 ; 初级篇 1、 进入数据库 mysql -u 用户名 -p 密码 2、 导出数据库 mysqldump -u 用户名 -p 密码 数据库名（表名）> 路径 备份.sql 3、 导入数据库 mysql -u 用户名 -p 密码 数据库名< 路径 备份.sql 或者进入mysql，使用source 路径 备份 此方法可以单独导入表 4、 显示所有数据库 show databases; 5、 使用数据库 use 数据库名; 6、 显示所有表 show tables; 7、 创建数据库 create database 数据库名; 8、 创建表 create table 表名(变量名 变量类型（大小）约束条件,变量名 变量类型（变量大小）约束条件,primary key(主键) ); 9、 描述表 describe 表名; 10、向表中输入数据 insert into 表名 values（ ）; 11、select 列 from 表 order by 列 desc/asc select count(*) from 表名 统计表中记录总数 descending 降序排列的意思 ascending 升序排列 12、删除表内容 delete from 表名 truncate table 表名 13、更新表内容

面试的时候被面试官问到sql语句的性能优化，回来百度才发现我了解的那些真的是凤毛麟角，废话不多说，上干货： 1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默 认值。 3，应尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。 4，应尽量避免在 where 子句中使用 or 来连接条件， 否则将导致引擎放弃使用索引而进行全表扫描， 可以 使用UNION合并查询： select id from t where num=10 union all select id from t where num=20 5，in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了：Select id from t where num between 1 and 3 6，下面的查询也将导致全表扫描：select id from t where name like ‘%abc%’ 或者select id from t

背景 系统结构如上图。经过排查是因为 系统B拉取数据时间太长导致的推送超时。 系统B拉取数据的方法是根据_tiemstamp(数据操作时间)分页查询系统A的接口,即： 1SELECT 字段名2FROM 表名3WHERE _timestamp >= beginTime AND _timestamp <= endTime 4LIMIT n, m; 由于该数据是从其他数据源中导入的，所以_timestamp这个字段值几乎相同，这就导致了在我们的查询范围内存在大约 150万 的数据。一般遇到这种情况，首先想到的就是 是否需要给_timestamp添加索引 ，这张表上是存在_timestamp索引的。那么为什么还会出现这个问题呢？这就要从分页查询本身说起了。 分页查询的性能瓶颈 B+树简述 首先我们要了解InnoDB存储引擎中的B+数索引。这里我简单总结一下： 上图是一颗B+树，通过观察我们可以发现它的一些特点：   1.每个节点中子节点个个数不能少于m/2个，不能大于m个(B+树是一颗m叉树，图中m=3)   2.根节点的节点个数可以超过m/2个，这是一个例外 上述两点特性是为了保证B+树的查询效率。 节点数超过m越多，在总节点数相同的情况下，树的高度h就越小，此时m叉数就会向链表退化(O(logn)->O(n))。   节点数小于m/2越多，在总节点数相同的情况下，树的高度h就越高

查看语句 查看所有数据库 show databases; 查看表结构 desc table_name; 查看库中所有表 show tables； 查看建表语句 show create table <table_name> ; 新建表语句 新建表： create table user( id int unsigned not null auto_increment comment '用户id', uesr_name varchar(20) not null comment '用户名', email varchar(50) not null comment '用户邮箱', age tinyint unsigned not null comment '用户年龄', fee decimal(10,2) not null default 0.00 comment '用户余额', created_at timestamp not null comment '注册时间', primary key(id) ); 字译说明 unsigned：无符号 tinyint：最小int decimal：准确，不四舍五入 timestamp：时间戳 comment：备注 DDL： alter table 修改表操作 alter table 表名 modify 列名 列类型 --修改改列类型 alter

binlog binlog_format cang.baidu.com change master checklist clone session default-character-set du fdatasync fedora frm fsync hatemysql.com heartbeat innobackupex-1.5.1 innodb innodb_flush_log_at_trx_commit linux lock timeout log group capacity loose modprobe mount multi-master multi schema my.cnf mysql mysqlbinlog mysqld_multi option modifiers pickup112.bulog.cn replication secure CRT select into outfile solaris squid ssh ssh_config statement sync_binlog ubuntu VIP bond weave xmark xtrabackup 主备备的两个备机转为双master时出现的诡异slave lag问题 有三台MySQL服务器，a,b和c，复制关系为 a -> b -> c。a,b,c的server_id分别为1，2，3

连接：mysql -h主机地址 -u用户名 －p用户密码 （注:u与root可以不用加空格，其它也一样） 断开：exit （回车） 创建授权：grant select on 数据库.* to 用户名@登录主机 identified by \"密码\" 修改密码：mysqladmin -u用户名 -p旧密码 password 新密码 删除授权: revoke select,insert,update,delete om *.* fromtest2@localhost; 显示数据库：show databases; 显示数据表：show tables; 显示表结构：describe 表名; 创建库：create database 库名; 删除库：drop database 库名; 使用库：use 库名; 创建表：create table 表名 (字段设定列表); 删除表：drop table 表名; 修改表：alter table t1 rename t2 查询表：select * from 表名; 清空表：delete from 表名; 备份表: mysqlbinmysqldump -h(ip) -uroot -p(password) databasenametablename > tablename.sql 恢复表: mysqlbinmysql -h(ip) -uroot -p

独立索引： 　　独立索引是指索引列不能是表达式的一部分，也不能是函数的参数 　　 例1： SELECT actor_id FROM actor WHERE actor_id+1=5 --这种写法，就算在actor_id上建立了索引，也不起效 　　 例2: SELECT .... WHERE TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col) <= 10 --这也是一种错误的写法 多列索引（联合索引）&选择合适的索引列顺序： 　　多列索引（Multiple-Column Indexes）也称为复合索引（composite index），也即同时对多个列建立索引。 　　什么时候用多列索引？ 当出现服务器对多个索引做相交操作时(通常有多个AND条件)，通常意味着需要一个包含所有相关列的多列索引，而不是多个独立的单列索引。 当服务器需要对多个索引做联合操作时(通常有多个OR条件)，通常需要耗费大量CPU和内存资源在算法的缓存、排序和合并操作上。特别是当其中有些索引的选择性不高，需要合并扫描返回大量数据的时候。 　　多列索引的生效规则： 　　比如(a,b,c)，abc都是拍好序的，在任意一段a的下面b都是排好序的,任何一段b下面c都是拍好序的。多列索引的生效原则是从前往后依次使用生效，如果中间某个索引没有使用，那么断点前面的索引部分起作用

前言：朋友说我运行一个简单的建议update声明失败。症状，如下面： mysql> update order_info set province_id=15 ,city_id= 1667 where order_from=10 and order_out_sn='1407261241xxxx'; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> QQ远程过去。開始check 1，查看数据库的隔离级别： mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) mysql> 2。去查看先当前库的线程情况： mysql> show full processlist; +----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+----------------