中间步骤自行设置
MySQL驱动版本根据自己安装的MySQL选择
我把AppTest改成了MybatisTest,不该也无妨;
其中Student类暂时只设置四个字段:
mapper接口暂时为空
在resources目录下新建File命名为db.peoperties,配置如下内容:
提示:以上配置适用于MySQL8.X版本,5.X版本按照如下配置:
1、transactionManager:事务管理器;
type 事务管理类型:
JDBC(JdbcTransactionFactory);
MANAGED(ManagedTransactionFactory)
自定义事务管理器:实现TransactionFactory接口.type指定为全类名
2、dataSource:数据源
type :数据源类型
UNPOOLED(UnpooledDataSourceFactory);POOLED(PooledDataSourceFactory);
JNDI(JndiDataSourceFactory)
自定义数据源:实现DataSourceFactory接口,type是全类名
<mapper>:注册一个sql映射文件
1、注册映射文件
resource:引用类路径下的sql映射文件
mybatis/StudentMapperpper.xml
url:引用网路路径或者磁盘路径下的sql映射文件
file:///var/mappers/AuthorMapper.xml
2、注册接口
class:引用(注册)接口,
① 有sql映射文件,映射文件名必须和接口同名,并且放在与接口同一目录下;
② 没有sql映射文件,所有的sql都是利用注解写在接口上
推荐:
比较重要的,复杂的Dao接口我们来写sql映射文件
不重要,简单的Dao接口为了开发快速可以使用注解;
批量注册
需要在资源路径下(resources)建立和dao一样的文件目录来存放想xml映射文件,如:com.example.StudentMapperpper.xml
StudentMapper
在resources的mybatis目录下新建文件夹mapper,新建xml文件StudentMapper.xml
namespace :名称空间指定为接口的全类名
id :唯一标识
resultType :返回值类型
#{id} :从传递过来的参数中取出id值
resources目录(MajorMapper.xml暂时不用创建)如下:
my.cnf 是mysql启动时加载的配置文件,一般会放在mysql的安装目录中,用户也可以放在其他目录加载。
安装mysql后,系统中会有多个 my.cnf 文件,有些是用于测试的。
安装locate
命令
输出
当我们需要修改配置文件时,需要找到mysql启动时是加载了哪个 my.cnf 文件。
启动mysql后,我们查看mysql的进程,看看是否有设置使用指定目录的 my.cnf 文件,如果有则表示mysql启动时是加载了这个配置文件。
命令
输出
可以看到 /usr/local/Cellar/mysql/5.6.24/my.cnf 就是mysql启动加载的配置文件。
如果上面的命令没有输出,表示没有设置使用指定目录的 my.cnf 。
如果没有设置使用指定目录的 my.cnf ,mysql启动时会读取安装目录根目录及默认目录下的 my.cnf 文件。
查看mysql启动时读取配置文件的默认目录
命令
输出
这些就是mysql默认会搜寻 my.cnf 的目录,顺序排前的优先。
如果没有设置使用指定目录 my.cnf 文件及默认读取目录没有 my.cnf 文件,表示mysql启动时并没有加载配置文件,而是使用默认配置。
需要修改配置,可以在mysql默认读取的目录中,创建一个 my.cnf 文件(例如: /etc/my.cnf ),把需要修改的配置内容写入,重启mysql后即可生效。
mysql的优化大的有两方面:
1、配置优化
配置的优化其实包含两个方面的: *** 作系统内核的优化和mysql配置文件的优化
1)系统内核的优化对专用的mysql服务器来说,无非是内存实用、连接数、超时处理、TCP处理等方面的优化,根据自己的硬件配置来进行优化,这里不多讲;
2)mysql配置的优化,一般来说包含:IO处理的常用参数、最大连接数设置、缓存使用参数的设置、慢日志的参数的设置、innodb相关参数的设置等,如果有主从关系在设置主从同步的相关参数即可,网上的相关配置文件很多,大同小异,常用的设置大多修改这些差不多就够用了。
2、sql语句的优化
1) 尽量稍作计算
Mysql的作用是用来存取数据的,不是做计算的,做计算的话可以用其他方法去实现,mysql做计算是很耗资源的。
2)尽量少 join
MySQL 的优势在于简单,但这在某些方面其实也是其劣势。MySQL 优化器效率高,但是由于其统计信息的量有限,优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join,一方面由于其优化器受限,再者在 Join 这方面所下的功夫还不够,所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于这些数据库前辈
3)尽量少排序
排序 *** 作会消耗较多的 CPU 资源,所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL的响应时间。
对于MySQL来说,减少排序有多种办法,比如:
通过利用索引来排序的方式进行优化
减少参与排序的记录条数
非必要不对数据进行排序
4)尽量避免 select *
在数据量少并且访问量不大的情况下,select * 没有什么影响,但是量级达到一定级别的时候,在执行效率和IO资源的使用上,还是有很大关系的,用什么字段取什么字段,减少不必要的资源浪费。
5)尽量用 join 代替子查询
虽然 Join 性能并不佳,但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题,虽然这个问题已经存在多年,但是到目前已经发布的所有稳定版本中都普遍存在,一直没有太大改善。虽然官方也在很早就承认这一问题,并且承诺尽快解决,但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)