MyISAM

参考： https://www.cnblogs.com/xiaohan666/p/9272581.html 解决Transactional注解不回滚 1. 检查你方法是不是public的。 2. 你的异常类型是不是unchecked异常。空指针异常是unchecked异常 如果我想check异常也想回滚怎么办，注解上面写明异常类型即可。 @Transactional(rollbackFor={Exception.class.RuntimeException.class}) 类似的还有norollbackFor，自定义不回滚的异常。 另外 如果已经在service中进行了try catch 操作 由于已经被抓获异常 故事务也不会回滚 3. 数据库引擎要支持事务，如果是mysql，注意表要使用支持事务的引擎，比如innodb，如果是myisam，事务是不起作用的。 4. 是否开启了对注解的解析 <tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"/> 5. spring是否扫描到你这个包，如下是扫描到org.test下面的包 <context:component-scan base-package="org.test" ></context:component

1、大数据的文件读取 利用生成器generator 迭代器进行迭代遍历：for line in file 2、迭代器和生成器的区别 迭代器是一个更加抽象的概念，任何对象，如果它的类有next方法和iter方法返回自身。对于string、list、dict、tuple等这类容器对象，使用for循环遍历是很方便的。在后台for语句对容器对象调用iter()函数，iter()是Python的内置函数。iter()会返回一个定义了next()方法的迭代器对象，它在容器中逐个访问容器内元素，next()也是python的内置函数。在没有后续元素时，next()会抛出一个StopIterration的异常。 生成器（Generator）是创建迭代器的简单而强大的工具。它们写起来就像是正规的函数，只是在返回数据的时候需要使用yield语句。每次next()被调用时，生成器会返回它脱离的位置（它记忆语句最后一次执行的位置和所有的数据值） 区别：生成器能做到迭代器能做的所有事，而且因为自动创建了__iter__()和next()方法，生成器显得特别简洁，而且生成器也是高效的，使用生成器表达式取代列表解析可以同时节省内存。除了创建和保持程序状态的自动生成，当发生器终结时，还会自动跑出StopIterration异常。 3.装饰器的作用和功能 引入日志 函数执行时间统计 执行函数钱预备处理

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。 MySQL锁概述 相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MySQL这3种锁的特性可大致归纳如下。 开销、加锁速度、死锁、粒度、并发性能 l 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。 l 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 l 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

Mysql 的存储引擎,myisam和innodb的区别。 答： 1.MyISAM 是非事务的存储引擎，适合用于频繁查询的应用。表锁，不会出现死锁，适合小数据，小并发。 2.innodb是支持事务的存储引擎，合于插入和更新操作比较多的应用，设计合理的话是行锁（最大区别就在锁的级别上），适合大数据，大并发。 数据表类型有哪些 答：MyISAM、InnoDB、HEAP、BOB,ARCHIVE,CSV等。 MyISAM：成熟、稳定、易于管理，快速读取。一些功能不支持（事务等），表级锁。 InnoDB：支持事务、外键等特性、数据行锁定。空间占用大，不支持全文索引等。 MySQL数据库作发布系统的存储，一天五万条以上的增量，预计运维三年,怎么优化？ a. 设计良好的数据库结构，允许部分数据冗余，尽量避免join查询，提高效率。 b. 选择合适的表字段数据类型和存储引擎，适当的添加索引。 c. mysql库主从读写分离。 d. 找规律分表，减少单表中的数据量提高查询速度。 e。添加缓存机制，比如memcached，apc等。 f. 不经常改动的页面，生成静态页面。 g. 书写高效率的SQL。比如 SELECT * FROM TABEL 改为 SELECT field_1, field_2, field_3 FROM TABLE. 对于大流量的网站,您采用什么样的方法来解决各页面访问量统计问题？

http://blog.csdn.net/jesseyoung/article/details/40617031 1 简介 在MySQL中，数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个，取决于存储引擎)。因此，所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。 在大多数Unix中数据库名和表名对大小写敏感，而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X，它基于Unix但使用默认文件系统类型(HFS+)，对大小写不敏感。然而，Mac OS X也支持UFS卷，该卷对大小写敏感，就像Unix一样。 变量 lower_case_file_system 说明是否数据目录所在的文件系统对文件名的大小写敏感。ON说明对文件名的大小写不敏感，OFF表示敏感。 例如在windows下查看： 说明windows系统对大小写不敏感，mysql也默认设置为对大小写不敏感。 2 大小写区分规则 linux下： 数据库名与表名是严格区分大小写的； 表的别名是严格区分大小写的； 列名与列的别名在所有的情况下均是忽略大小写的； 变量名也是严格区分大小写的； windows下： 都不区分大小写 Mac OS下（非UFS卷）： 都不区分大小写 3 参数说明（lower_case_table_names） unix下lower_case

概述 热点数据通俗的讲是指被高频使用到的数据，比如某些热点事件，由于网络的发酵效应，短时间能够达到几十万甚至上百万的并发量，针对这类场景，我们需要分析系统瓶颈所在，以及应对的技术实现 方案讲解 大并发架构演进 1、图1和图2的区别是中间会有一层web缓存服务器，该服务它可以由nginx+lua+redis进行设计完成，缓存层的热点数据分散，将会在后续的‘高并发度’章节做介绍。 2、热点数据肯定能在web层的缓存服务器被拦截住，防止把大量的请求打到应用服务器，但是对于非热点的数据穿透缓存后会请求至DB，这部分数据每秒几千的QPS对DB造成的压力也是非常大的，这个时候我们需要一定的方案，保证请求的时效性，就是如何降低DB层面的IO次数 场景分类 热点数据并发分为读和写两种场景，日常高并发遇到的大多数都是读场景，无论是采用何种的架构设计，都需要在缓存层和DB层面做热点数据的分散，本章着重介绍后者 原理分析 大家都知道对热点数据分散后，系统的性能会有显著提升，是什么原理导致的，接下来我们探讨一下db存储的一些关键知识，上面两个是大家经常用到的两种mysql存储引擎，尤其是后者，基本上笔者在工作中遇到的绝大多数的表都定义成了innodb引擎，两者的差异在哪里？使用场景的区别在什么地方？ 1、读数据 myisam ：与innodb一样都采用BTREE实现，myisam是非聚集索引

一、为什么用自增列作为主键？ 　　1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。 　　如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。 　　如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。 　　2、数据记录本身被存于主索引（一颗B+Tree）的叶子节点上，这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放 　　因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点） 　　3、如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页 　　4、如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置 　　此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销 　　同时频繁的移动、分页操作造成了大量的碎片

推荐阅读(点击即可跳转阅读) SpringBoot内容聚合 面试题内容聚合 设计模式内容聚合 Mybatis内容聚合 多线程内容聚合 本文概要 概述 为什么要优化 系统的吞吐量瓶颈往往出现在数据库的访问速度上 随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢 数据是存放在磁盘上的，读写速度无法和内存相比 如何优化 设计数据库时：数据库表、字段的设计，存储引擎 利用好MySQL自身提供的功能，如索引等 横向扩展：MySQL集群、负载均衡、读写分离 SQL语句的优化（收效甚微） 字段设计 字段类型的选择，设计规范，范式，常见设计案例 原则：尽量使用整型表示字符串 存储IP INET_ATON(str) ，address to number INET_NTOA(number) ，number to address MySQL内部的枚举类型（单选）和集合（多选）类型 但是因为维护成本较高因此不常使用，使用 关联表 的方式来替代 enum 原则：定长和非定长数据类型的选择 decimal不会损失精度，存储空间会随数据的增大而增大。double占用固定空间，较大数的存储会损失精度。非定长的还有varchar、text 金额 对数据的精度要求较高，小数的运算和存储存在精度问题（不能将所有小数转换成二进制） 定点数decimal price decimal(8,2)

表 存储引擎种类： MyISAM结构： .frm文件：存储表数据定义、表结构 .MYD文件：存储表数据行 .MYI文件：存储表的索引，存储在b+tree里面 MyISAM存储引擎结构： 根据col=49，根据b+tree快速定位到49，获取磁盘指针（values） 0X90 ，从而获取表数据； InnoDB结构存储引擎：必须需要有主键，为啥？ .ibd文件：索引文件和 数据行合并 MyISAM和InnoDB 区别： MyISAM： 索引所在磁盘指针 InnoDB： 索引所在行其他字段存储 聚集索引：索引和数据在一起 非聚集索引：从一个文件去获取另一个文件，索引和数据没有在一起 问题： InnoDB结构存储引擎：必须需要有主键，为啥？ 如果InnoDB表没有主键，mysql会从表中寻找一个可以唯一标识的主键， 如果找不到，他会生成默认列（隐藏列）。来维护数据。 UUID：长串字符串，占有存储空间，比较慢等 为何使用自增主键？ 后面大于前面，一次追加，满足叶子节点 联合索引的底层结构： 小的放左边，相同的比较下面的参数。 来源： https://my.oschina.net/u/3915790/blog/3102123

On my site I have a visitor's table with 10 million rows. Every request to the site inserts row to the table, in case the table is locked (usually in optimize query) visitors can't get into the site The table engine is MyISAM and I want to change it to InnoDB I have few questions: How can I change the table engine without stoping my site from working There is a way to optimize InnoDB table without locking it The easiest way is ALTER TABLE table_name ENGINE = InnoDB; If you use InnoDB engine you should not worry about locking tables, because this engine locks data by rows. oleksii.svarychevskyi