1.两种查询引擎查询速度（myIsam 引擎 ）
 
InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行。
 
MyISAM只要简单的读出保存好的行数即可。
 
注意的是，当count()语句包含 where条件时，两种表的操作有些不同，InnoDB类型的表用count()或者count(主键)，加上where col 条件。其中col列是表的主键之外的其他具有唯一约束索引的列。这样查询时速度会很快。就是可以避免全表扫描。
 
总结：
 
mysql 在300万条数据（myisam引擎）情况下使用 count(*) 进行数据总数查询包含条件（正确设置索引）运行时间正常。对于经常进行读取的数据我们建议使用myIsam引擎。
 
2.百万数据下mysql分页问题
 
在开发过程中我们经常会使用分页，核心技术是使用limit进行数据的读取，在使用limit进行分页的测试过程中，得到以下数据：
 
select * from news order by id desc limit 0,10
 耗时0.003秒
 select * from news order by id desc limit 10000,10
 耗时0.058秒
 select * from news order by id desc limit 100000,10
 耗时0.575秒
 select * from news order by id desc limit 1000000,10
 耗时7.28秒
 
我们惊讶的发现mysql在数据量大的情况下分页起点越大查询速度越慢，100万条起的查询速度已经需要7秒钟。这是一个我们无法接受的数值！
 
改进方案 1
 
select * from news
 where id > (select id from news order by id desc limit 1000000, 1)
 order by id desc
 limit 0,10
 
查询时间 0.365秒，提升效率是非常明显的！！原理是什么呢？？？
 
我们使用条件对id进行了筛选，在子查询 (select id from news order by id desc limit 1000000, 1) 中我们只查询了id这一个字段比起select * 或 select 多个字段 节省了大量的查询开销！
 
改进方案2
 
适合id连续的系统，速度极快！
 
select * from news
 where id between 1000000 and 1000010
 order by id desc
 
不适合带有条件的、id不连续的查询。速度非常快！
 
百万数据下mysql条件查询、分页查询的注意事项
 
接上一节，我们加上查询条件：
 
select id from news
 where cate = 1
 order by id desc
 limit 500000 ,10
 
查询时间 20 秒
 
好恐怖的速度！！利用第一节知识进行优化：
 
select * from news
 where cate = 1 and id > (select id from news where cate = 1 order by id desc limit 500000,1 )
 order by id desc
 limit 0,10
 
查询时间 15 秒
 
优化效果不明显，条件带来的影响还是很大！在这样的情况下无论我们怎么去优化sql语句就无法解决运行效率问题。那么换个思路：建立一个索引表，只记录文章的id、分类信息，我们将文章内容这个大字段分割出去。
 
表 news2 [ 文章表 引擎 myisam 字符集 utf-8 ]
 
 
id int 11 主键自动增加
 
cate int 11 索引
 
在写入数据时将2张表同步，查询是则可以使用news2 来进行条件查询：
 
select * from news
 where cate = 1 and id > (select id from news2 where cate = 1 order by id desc limit 500000,1 )
 order by id desc
 limit 0,10
 
注意条件 id > 后面使用了news2 这张表！
 
运行时间 1.23秒，我们可以看到运行时间缩减了近20倍！！数据在10万左右是查询时间可以保持在0.5秒左右，是一个逐步接近我们能够容忍的值！
 
但是1秒对于服务器来说依然是一个不能接受的值！！还有什么可以优化的办法吗？？我们尝试了一个伟大的变化：
 
将 news2 的存储引擎改变为innodb，执行结果是惊人的！
 
select * from news
 where cate = 1 and id > (select id from news2 where cate = 1 order by id desc limit 500000,1 )
 order by id desc
 limit 0,10
 
只需要 0.2秒，非常棒的速度。
 
4.mysql存储引擎 myIsam和innodb的区别
 
MySQL有多种存储引擎，MyISAM和InnoDB是其中常用的两种。这里介绍关于这两种引擎的一些基本概念（非深入介绍）。
 
MyISAM存储引擎，基于传统的ISAM类型，支持全文搜索，但不是事务安全的，而且不支持外键。每张MyISAM表存放在三个文件中：frm 文件存放表格定义；数据文件是MYD (MYData)；索引文件是MYI (MYIndex)。
 
InnoDB是事务型引擎，支持回滚、崩溃恢复能力、多版本并发控制、ACID事务，支持行级锁定（InnoDB表的行锁不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，如like操作时的SQL语句），以及提供与Oracle类型一致的不加锁读取方式。InnoDB存储它的表和索引在一个表空间中，表空间可以包含数个文件。
 
核心区别
 
MyISAM是非事务安全型的，而InnoDB是事务安全型的。
 
MyISAM锁的粒度是表级，而InnoDB支持行级锁定。
 
MyISAM支持全文类型索引，而InnoDB不支持全文索引。
 
MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
 
MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。
 
InnoDB表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表（alter table tablename type=innodb）。
 
应用场景
 
MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
 
InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。
 
Mysql的存储引擎和索引
 
数据库必须有索引，没有索引则检索过程变成了顺序查找，O(n)的时间复杂度几乎是不能忍受的。我们非常容易想象出一个只有单关键字组成的表如何使用B+树进行索引，只要将关键字存储到树的节点即可。当数据库一条记录里包含多个字段时，一棵B+树就只能存储主键，如果检索的是非主键字段，则主键索引失去作用，又变成顺序查找了。这时应该在第二个要检索的列上建立第二套索引。 这个索引由独立的B+树来组织。有两种常见的方法可以解决多个B+树访问同一套表数据的问题，一种叫做聚簇索引（clustered index ），一种叫做非聚簇索引（secondary index）。这两个名字虽然都叫做索引，但这并不是一种单独的索引类型，而是一种数据存储方式。对于聚簇索引存储来说，行数据和主键B+树存储在一起，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说，主键B+树在叶子节点存储指向真正数据行的指针，而非主键。
 
InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。
 
MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。
 
为了更形象说明这两种索引的区别，我们假想一个表如下图存储了4行数据。其中Id作为主索引，Name作为辅助索引。图示清晰的显示了聚簇索引和非聚簇索引的差异。
 
我们重点关注聚簇索引，看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？
 
1 由于行数据和叶子节点存储在一起，这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。
 
2 辅助索引使用主键作为"指针" 而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置（实现中通过16K的Page来定位，后面会涉及）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。
 
所以在百万级数据及更大数据情况下，mysql innoDB 的索引表现更加优秀！
 
5、MySQL性能优化的一些经验
 
a.为查询优化你的查询
 
大多数的MySQL服务器都开启了查询缓存。这是提高性能最有效的方法之一，而且这是被MySQL的数据库引擎处理的。当有很多相同的查询被执行了多次的时候，这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不用操作表而直接访问缓存结果了。
 
这里最主要的问题是，对于程序员来说，这个事情是很容易被忽略的。因为，我们某些查询语句会让MySQL不使用缓存。
 
请看下面的示例：
 
// 查询缓存不开启
 
$r = mysql_query(“SELECT username FROM user WHERE signup_date >= CURDATE()”);
 
// 开启查询缓存
 
$today = date(“Y-m-d”);
 
$r=mysq{l}_{q}uery("SELECTusernameFROMuserWHEREsignu{p}_{d}ate>{=}^{\prime }$today’");
 
上面两条SQL语句的差别就是 CURDATE() ，MySQL的查询缓存对这个函数不起作用。所以，像 NOW() 和 RAND() 或是其它的诸如此类的SQL函数都不会开启查询缓存，因为这些函数的返回是会不定的易变的。所以，你所需要的就是用一个变量来代替MySQL的函数，从而开启缓存。
 
b.学会使用EXPLAIN
 
使用EXPLAIN关键字可以让你知道MySQL是如何处理你的SQL语句的。
 
select id, title, cate from news where cate = 1
 
发现查询缓慢，然后在cate字段上增加索引，则会加快查询
 
c.当只要一行数据时使用LIMIT 1
 
当你查询表的有些时候只需要一条数据，请使用 limit 1。
 
d.正确的使用索引
 
索引并不一定就是给主键或是唯一的字段。如果在你的表中，有某个字段你总要会经常用来做搜索、拍下、条件，那么，请为其建立索引吧。
 
e.不要ORDER BY RAND()
 
效率很低的一种随机查询。
 
f.避免SELECT *
 
从数据库里读出越多的数据，那么查询就会变得越慢。并且，如果你的数据库服务器和WEB服务器是两台独立的服务器的话，这还会增加网络传输的负载。必须应该养成一个需要什么就取什么的好的习惯。
 
g.使用 ENUM 而不是 VARCHAR
 
ENUM 类型是非常快和紧凑的。在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这样一来，用这个字段来做一些选项列表变得相当的完美。
 
如果你有一个字段，比如“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。
 
h.使用 NOT NULL
 
除非你有一个很特别的原因去使用 NULL 值，你应该总是让你的字段保持 NOT NULL。这看起来好像有点争议，请往下看。
 
首先，问问你自己“Empty”和“NULL”有多大的区别（如果是INT，那就是0和NULL）？如果你觉得它们之间没有什么区别，那么你就不要使用NULL。（你知道吗？在 Oracle 里，NULL 和 Empty 的字符串是一样的！)
 
不要以为 NULL 不需要空间，其需要额外的空间，并且，在你进行比较的时候，你的程序会更复杂。 当然，这里并不是说你就不能使用NULL了，现实情况是很复杂的，依然会有些情况下，你需要使用NULL值。
 
下面摘自MySQL自己的文档
 
“NULL columns require additional space in the row to record whether their values are NULL. For MyISAM tables, each NULL column takes one bit extra, rounded up to the nearest byte.”
 
i.IP地址存成 UNSIGNED INT
 
很多程序员都会创建一个 VARCHAR(15) 字段来存放字符串形式的IP而不是整形的IP。如果你用整形来存放，只需要4个字节，并且你可以有定长的字段。而且，这会为你带来查询上的优势，尤其是当你需要使用这样的WHERE条件：IP between ip1 and ip2。
 
我们必需要使用UNSIGNED INT，因为 IP地址会使用整个32位的无符号整形
 
j.固定长度的表会更快
 
如果表中的所有字段都是“固定长度”的，整个表会被认为是 “static” 或 “fixed-length”。 例如，表中没有如下类型的字段： VARCHAR，TEXT，BLOB。只要你包括了其中一个这些字段，那么这个表就不是“固定长度静态表”了，这样，MySQL 引擎会用另一种方法来处理。
 
固定长度的表会提高性能，因为MySQL搜寻得会更快一些，因为这些固定的长度是很容易计算下一个数据的偏移量的，所以读取的自然也会很快。而如果字段不是定长的，那么，每一次要找下一条的话，需要程序找到主键。
 
并且，固定长度的表也更容易被缓存和重建。不过，唯一的副作用是，固定长度的字段会浪费一些空间，因为定长的字段无论你用不用，他都是要分配那么多的空间。
 
k.垂直分割
 
“垂直分割”是一种把数据库中的表按列变成几张表的方法，这样可以降低表的复杂度和字段的数目，从而达到优化的目的。需要注意的是，这些被分出去的字段所形成的表，你不会经常性地去Join他们，不然的话，这样的性能会比不分割时还要差，而且，会是极数级的下降。
 
l.拆分大的 DELETE 或 INSERT 语句
 
如果在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。
 
Apache 会有很多的子进程或线程。所以，其工作起来相当有效率，而我们的服务器也不希望有太多的子进程，线程和数据库链接，这是极大的占服务器资源的事情，尤其是内存。
 
如果你把你的表锁上一段时间，比如30秒钟，那么对于一个有很高访问量的站点来说，这30秒所积累的访问进程/线程，数据库链接，打开的文件数，可能不仅仅会让你泊WEB服务Crash，还可能会让你的整台服务器马上掛了。
 
m.越小的列会越快
 
对于大多数的数据库引擎来说，硬盘操作可能是最重大的瓶颈。所以，把你的数据变得紧凑会对这种情况非常有帮助，因为这减少了对硬盘的访问。
 
n.选择正确的存储引擎
 
在 MySQL 中有两个存储引擎 MyISAM 和 InnoDB，每个引擎都有利有弊。
 
MyISAM 适合于一些需要大量查询的应用，但其对于有大量写操作并不是很好。甚至你只是需要update一个字段，整个表都会被锁起来，而别的进程，就算是读进程都无法操作直到读操作完成。另外，MyISAM 对于 SELECT COUNT(*) 这类的计算是超快无比的。
 
InnoDB 的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比 MyISAM 还慢。他是它支持“行锁” ，于是在写操作比较多的时候，会更优秀。并且，他还支持更多的高级应用，比如：事务。

告诉你一个真实的银行业
 
写这篇文章的目的主要是让银行股投资者对银行的经营有一个基本的概念，另外可能对想了解银行或者毕业想进入银行的小伙伴有一些帮助。恰好自己在银行从业过三年，也经历过很多岗位。所以把自己的一些认识和了解写下来，希望对大家有所帮助。
 
 
 
 
运营篇
 
首先要声明的是我所在的是一家全国性股份制银行，所以他的架构与股份制银行基本相似的。与四大行有些区别，因为四大行网点多，所以分的更细，他们有分一级分（支）行和二级分（支）行。但是总体的结构还是相似的。
 
首先说支行吧！支行是构成一家银行经营的基本单位。那么支行又是如何构成的？支行分为运营条线、零售条线、对公条线。
 
运营条线由什么构成？运营就是由防弹玻璃窗后面那些漂亮的桂圆美眉构成。运营条线的兵就是桂圆，再加两个会计主管和一个运营部主任。桂圆又分为做储蓄业务的桂圆和做对公业务的桂圆，储蓄桂圆主要服务个人客户。
 
储蓄桂圆的工作包括：开储蓄卡、开网银、开手机银行、修改密码，办理存取款，转账。办理结售汇，开存款证明，协助理财经理完成客户买理财、保险等。另外有一些营销类的工作，一般不是强制的，但是完成有奖励，比如营销一张白金信用卡有90块奖励，营销一个贵宾客户有300块左右奖励（一般资产达到30万就算贵宾，贵宾可以享受一些免费或者便捷的服务，比如免费打印一年以上流水，比如刷vip号不用排队等，银行一般都设有vip窗口）。
 
对公桂圆的工作包括：开对公账户，开承兑汇票，转账，同城票交等与公司相关的业务。
 
桂圆的考核很简单：主要看你做的业务的速度以及是否有差错。银行会根据你做业务的笔数以及难易程度计分，这里一般很难拉开差距。对桂圆的收入影响最重要的是一年一次的等级考试。考试的内容主要是三项：打字速度，打传票速度（就是录数字的速度），以及识别假钞（一般十张里面会有两三张），桂圆每年考试前都要抽时间练盲打。考试成绩高加上工作年限长，等级就越高，岗位工资越高。在广州一个一般桂圆的工资到手在6000左右。
 
再说一下桂圆的升迁路径：桂圆如果留在运营条线，那么升迁路径就是会计主管，一般快的话也要两三年才能做到。会计主管再做个三五年有机会升迁营业部主任。营业部主任基本就到顶了，最多再升个支行副行长。极少数能去分行运营部做副手。
 
桂圆的另外一条出路就是转岗，做理财经理或者对公客户经理。能不能转岗要看你平时的营销业绩怎么样，有没有客户资源。当然最重要的还是支行行长认为你有做营销工作的能力。所以想转岗的桂圆要积极营销，另外要多跟领导汇报工作，表达想法。一般校招进银行的都要从桂圆岗位做起，包括研究生，所以很多研究生最后没有出彩就慢慢的一直停留在桂圆岗位，严重浪费了教育资源。
 
银行之所以有这个规定，那是因为做过桂圆的客户经理，能够解答客户的一些日常业务的操作流程，减少沟通成本，给客户一种专业的印象。没做过桂圆的客户经理往往很多业务都不懂，总要去问桂圆之后才能答复客户。另外，做过桂圆的客户经理一般风险意识很强。你想想，桂圆坐在那狭窄的空间里，有摄像头盯着，有会计主管监督，有神秘人（银行外包给第三方的监督人员）巡视，所以抠个鼻屎都不敢。离开座位没锁屏，马上扣分。所以各位去银行办事的要对桂圆美眉客气点。
 
再来说一下会计主管这个职位：他的职责主要是授权桂圆办一些业务，比如提现超过5万，转账超过50万，开户人脸识别不能通过之类的。每天下班后要复合桂圆每天的业务传票，流水。看有没有漏掉客户签名。要复合桂圆的重要空白凭证（指空白的银行卡、存单之类的）是否相符。最后就是安排桂圆的班次，以及每天安排两个（银行的很多业务都要双人复核）桂圆等押运公司的人来把现金以及重要的空白凭证取走。这样一天的营业就结束了。
 
主管的考核主要是：整个网点的业务量、差错占比、是否有客户投诉等。会计主管的工资一般比桂圆高2000左右，在广州到手大概8000左右。
 
营业部主任的工作：主要传达分行营业部的一些指示，所以参加会议比较多，主要关于反洗钱、银行卡账户诈骗之类的。另一方面就是要协助支行行长在合规和客户便捷方面去权衡。因为支行行长基本都是站在客户角度的，而营业部主任是站在合规角度的，并且营业部主任的薪酬升迁等基本与支行行长关系不大。这样做的目的主要是基于防范风险考虑。如果支行行长与营业部主任勾结犯罪，会产生很大的威力。营业部主任的工资到手在15000左右，考核主要是整个网点的合规方面有没有被扣分，比如桂圆没有按照流程办业务，比如网点桂圆有没有被监控抓到抠鼻屎之类的。另外还有一部分考核是桂圆对营部主任的打分，影响不大。
 
分行的运营部门主要职能一方面是监督检查支行运营条线、检查分行职能部门，安排支行桂圆的培训等，另一方面做一些分行部门上收的业务，比如对外汇款的后续处理等。第三个就是支行与总行之间的桥梁作用，包括一些信息的传达等。
 
总之，运营条线基本的功能主要是在合规的基础上帮助客户办理具体业务，基本不产生利润。银行的运营条线就先写到这里，如果大家有需求再写其他条线！
 
 
 
对公篇
 
对公是银行最为重要的业务，也是银行股投资者最关心的业务。因为银行主要的资产还是企业贷款。这点可以从支行的人员配置可以看出来，支行的行长基本都是做对公业务出身的，所以想要在分支行层面有所发展，从对公客户经理做起比其他选择要好，另外最好当然是选一家家底厚的支行做对公客户经理，待遇好，升职快。支行的对公业务一般的构成是：支行行长、对公副行长、对公客户经理。
  
 
支行行长的具体职责当然是主持整个支行的工作。但是支行行长一般都会把精力花在对公业务方面，零售和运营一般直接甩给管零售的副行长。因为对公业务规模起的快，有规模才有利润、在分行才有地位，才有升迁的可能。所以大家不要对银行的规模情结奇怪！
 
另外支行的营销费用以及行长可以分配的业绩，也是与支行的kpi以及创收能力挂钩的。对公规模做的大，利润多，营销费用多。营销费用多，才能更好的开发和留住客户。比如每个季度都要采购茶叶、粮油、糖果等，用来维持与大型客户经办人员的关系，另外一部分用来开发和回馈个人的贵宾客户。经费越多，才能与客户把盏，才能更好的维护这些关系，才能进入正循环。一个业绩好的支行每个季度的营销费用在15万左右。
 
对公行长在对公业务方面的主要职责就是：出面对接一些大型或者重要客户的一把手，这些业务对公客户经理是搞不定的。尤其是国有企业，一般讲究地位对等，一把手只跟一把手谈，对公客户经理就在旁边记要点，谈好了底下的小弟就负责去落实。银行这边就是对公客户经理去落实。
 
这是对外方面的，对内方面就是支行行长要去跟分行领导说明一些项目的情况。如果他觉得某个公司可以放贷或者续贷，某个项目可以做，那么他就去跟信审的老总聊，如果信审的老总不放心，就带去企业看。如果还不批，就去找分行分管对公的副行长、分管风险的副行长汇报，去加速推进。
 
总之支行行长的职责就是对外搞定大客户，对内搞定大boss，加快项目推进。所以支行行长的信贷经验、判断能力、职业道德，对一个银行的对公坏账率有很大的影响。因为他身处一线，他的判断比报表、数字更具有参考性，所以在跟上面沟通的时候也更有话语权。一家效益好的支行的行长薪水在税前100万左右。
 
再来说一下对公副行长，对公副行长的职责就是管理整个对公团队，他的作用就是跟行长互补，行长管不过来的，对公副行长来管。他的升迁路径一般是等支行行长升迁或者调走了，接任。或者调到一家小一点的支行做一把手。
 
最后再来说一下对公客户经理。对公客户经理就是万金油，什么业务都要懂一点（银行几乎所有的业务都跟对公客户经理有关系，比如企业老板个人要理财，那么你要懂一点个人理财业务，比如他要发债券，那么你又要懂一点这个，再传达给分行金融市场部的人。比如他要质押股票等等）什么事都能聊，什么牛都敢吹，当然不排除有对公客户经理不是这样，但是做的好的客户经理基本都是这样。
 
对公客户经理的职责是什么？开发新客户、留住存量客户。至于怎么开发新客户，就是混各种圈子，校友圈、老乡圈、俱乐部等等，一嗅到机会就去拜访，级别不够就拉着领导去谈，谈方案、谈金额、谈价格，看能否达成共识。当确定一个项目或者贷款能做的时候就收集资料，写信贷报告，联系评估公司对抵押物进行评估。
 
这里说一下，贷款类型。最多就是流动资金贷款，就是用来周转的，期限一年。其他常见的还有，项目贷款，项目贷款就是比如企业要建厂房，通常要三年左右建成，三五年才能产生现金流还贷。还有就是开发贷，能获得开发贷的房地产商一般要在银行的白名单中，这里一般要求房地产商排名进入百强，所以大家要理解地产商拼命做规模。其他还有一些ppp项目、产业基金、股票质押贷款、委托贷款啊之类的，这些通常对应的是表外理财资金。
 
资料收齐了，信贷报告写好了，就提交给信贷审查部，通常要排队。所以为了加快推进，对公客户经理要跟审查人员搞好关系，多请别人吃吃饭，反正可以报销。当然这是分行层面的。一般贷款额度超过2亿就要提交总行审批，流程就会很长，除非是重大项目，有分行领导出面。
 
对公客户经理层面的事情还有很多，这里仅仅说了贷前调查和一部分贷中，贷后管理方面也有很多有趣的事，怎么跟客户、跟其他银行斗智斗勇，跟小贷公司，过桥公司周旋，可以写很多。
 
可以说银行的业务就是由千千万万个客户经理按照银行的规则来经营的，包括对公客户经理和零售的理财经理、个贷经理。但是对公客户经理又是这里面最重要的，因为对公资产占银行资产的绝对大头。当然像招行这种零售银行除外。
 
说到对公客户经理，不得不说他们的考核，因为考核就是一根指挥棒指引着对公客户经理的行为。对公客户经理的主要考核指标有：贷款规模、存款规模、创造的利润。其他还有一些小指标比如新增有效户个数之类的（有效户是指开户后资产留存达到一定级别的客户：比如100万）五迷做客户经理那会，初级客户经理的考核标准是贷款日均余额4000万，存款日均余额5000万，年创造利润150万。
 
初级经理还是比较容易达到的。但是薪水到手也就个七八千的样子。高级客户经理的月薪大概在2万到3万，资深就去到三万以上了。
 
之前说了贷款分为贷前、贷中、贷后。贷前调查就是初步洽谈感觉可以做后就实地考察工厂啊、公司啊。另外想要多提一点的是，贷款是如何定价的：一般的省级以上的国企或者其二级子公司，在资金充裕的时候价格通常是基准利率下浮10%，上市公司或者评级AAA以上的未上市民营企业基本都是基准利率，其他的民营企业都是基准上浮30%起。资金紧张的时候当然就是贵宾不贵，都要相应的提高。
 
为什么要说一下定价这个事情呢？因为很多银行股投资者不知道有些银行的公司的贷款平均收益率高意味着什么，你如果知道贷款是怎么定价的你就知道，贷款收益率越高，隐含的风险越大。那么这些银行为什么还要做这些高风险企业的业务呢？因为大的国企、上市公司等资源被四大行垄断了，为什么这些国企股份制挖不走呢？因为国企想要多开一个银行账户是很麻烦的，需要上级部门批准，更别说销掉基本户去其他银行开了。
 
好了，贷前调查的事情就聊到这里。贷中就是落地，联系评估公司评估抵押物。抵押物的抵押率一般是这样的：住宅的抵押率不超过七折，商铺不超过六折、厂房土地之类的不超过五折。只有前面提到的那些省级以上国企或者评级AAA的公司可以获得信用贷款。评估好了，就可以大概算出可以给企业多少额度，再写调查报告。
 
贷款调查报告，包括企业家的一些历史，怎么发家的，另外比较重要的是要查他个人和公司的征信，看他在其他银行的贷款情况，有没有逾期的，然后再查一查全国法院被执行情况，看有没有惹上什么烂事。然后对一些报税的单据、水电费、上下游流水进行分析，一般银行流水如果没有达到营收的1.5倍就会被认为有水分，所以有些企业要做账。大型企业需要提供经过银行指定的审计公司审计的财务报告，财报主要看现金流情况。客户经理如果觉得企业靠谱、行长也觉得靠谱，就尽量把这家企业写得好一点。
 
写好就按流程提交到信贷审查部，去磨去泡那些审查部的妹子，多沟通，额度在两亿以内的，信贷审查部经办人同意、老总签字、管风险的副行长签字之后就会出批复，然后你按着批复上的要求落实，把资料整理齐，包括企业和企业法人的资料，担保人资料，抵押物保险等等，按清单整理好，交给信贷管理部门，然后你就可以出账了。额度在两亿以上的要去到总行信贷审批中心，流程大体一样，但是信贷客户经理可能说不上什么话，等着回复问题即可。如果不放心，可以让支行行长去跟分行领导沟通。
 
大概是这么个流程，写的太细了，不过还有很多细节没写，好像投资银行股的投资者也不要知道那么多细节。总之给了企业钱之后，企业就是大爷了，一般银行对贷款资金的用途和去向都有规定的，所以一般会要求将结算留在这里，一方面监控资金去向，另一方面掌握企业经营情况。
 
对于不配合的企业就威胁下一年度贷款要慎重考虑。然后银行还会要求每个季度去公司检查一次，金额较大的支行行长必须亲自带主办客户经理去。去看看公司是否正常运作，要拍照、看看仓库、看看车间、跟公司负责人合影。然后每年贷款到期前三个月左右，就要开始决定是否续作。如果不续租，也要及时通知企业，让他找好下家，做好资金安排，别被抽贷压死了。另外，贷款的几乎所有流程采用双人负责制，一个主办对公客户经理，一个协办客户经理。
 
至于拉存款，很多人还停留在支行行长或者客户经理一杯酒拉100万或者1000万的偏见中，实际生这种情况只出现在经济发展的早期。现在基本已经尘埃落定了，好的公司都名花有主了，不是一杯酒就能拉来存款的，当然美女客户经理的一杯酒可能还是能拉来的，但是为了工作牺牲自己也不合算。存款还是要用产品来绑定，主要是贷款。其他的还有一些托管之类的也可以拉来存款。
 
贷款怎么拉存款？一个方法就是要求结算往来资金都要过来我这边，这种情况通常是你是主办银行，也就是你的给的贷款最多，他就过来。还有一种方法就是，然他把贷款变成存单存在你这里，比如这家企业需要1个亿的资金，那么你就给他2个亿的低风险贷款，也就是要求2个亿给到他之后，要把1个亿存在我这里，存定期，按一年期的定期利率给你，然后你可以开两个亿的银行承兑汇票。
 
能接受这种安排一般是没有选择的企业，因为差不多成倍的提高了他的融资成本，但是对他们来说能从银行贷到钱就是烧高香了。但是对客户经理是有好处的，即完成了贷款也完成了存款。利润方面也不错，因为企业的成本就是银行的营收。不过这种企业如果玩不好，就会砸自己手里，最后出不良。出了不良客户经理很惨的，很多直接从高级客户经理变为未定级，由于高级客户经理的住房公积金很高的，出了不良之后，往往还要自己垫钱交五险一金。如果金额特别大，比如几个亿，支行行长如果被证明有责任，会被降级的，不过这种情况很少发生，毕竟找个背锅的还是不难。
 
另外各个银行都非常眼红财政存款，因为财政存款比较稳定，而且不能做理财的，息差大。但是政府也是猴精猴精的，他会根据你给地方融资平台放贷款的多少，来决定给你多少财政存款。
 
其次医院的存款，银行也喜欢，一家大的医院往往可以养活一家支行。除了对公存款方面，医院的员工可以搞代发工资，大部分医生都是贵宾客户，再把理财信用卡补上，养活一家支行完全没问题。但是医院也聪明啊，银行要跟一家医院建立关系，通常要免费给他们清点现金，五迷当年在银行的时候也清点过，好多脏兮兮的钞票，有的还有血，清点到想吐。另外银行还要付钱请押运公司的人去医院收钱，运到银行，然后柜员清点入账，以前都需要专门安排一到两个柜员做这个事情。
 
总之贷款存款做好了，利润指标也自然完成了，如果想再高一点利润，就再做一点表外业务，比如股票质押，非标啊之类的。尤其是银行资本金紧张或者信贷额度紧张的时候，特别鼓励去做表外业务。所以表外业务占比高，大家知道意味着什么了吧？
 
 
 
零售篇
 
四大行中的中农建公布了业绩，初步看了一下，比较符合年初息差不良拐点的判断，然后兴业也公布了半年报，感觉有点惨。跟年初说的看好四大行加招行的判断相符。关键，这种分化还会持续下去。所以银行股一定要买最优秀的，才能体会什么叫做复利的威力。
 
言归正传，之前已经谈了支行条线中的运营和对公。还有零售条线没谈。零售条线可能是与我们息息相关的。支行零售条线的架构是，一个零售的副行长，3-5个理财经理，1到2个个贷经理，然后还有一个信用卡管理员。
 
首先说一下理财经理这个职位，前段时间有个招行的私行客户说因为相信理财经理，使得他在招行买的理财产品大幅亏损，这里他明显太相信理财客户经理了。其实我想跟大家说的是，理财经理就是一个销售，不懂投资的，没有你想象的那么专业。他就是根据你的风险偏好来跟你推荐产品，不能保证盈亏的。
 
首先，理财经理的考核比较重要的指标就是AUM和新增贵宾客户。AUM就是assets under management,名下管理的资产的意思。包括:存款，国债，理财，基金，保险等。这里我想说的是，在资管新规之前，银行的自己发行的理财产品都是刚兑的，但是不包括代销的，代销产品有哪些？比如信托产品、私募基金产品、包括公募基金，这些银行只是充当销售渠道，赚点佣金而已，这些出了事银行是不会保本的。当然考虑到自己的声誉，银行会谨慎的选择合作的信托机构、私募机构。
 
资管新规后，最终都会过度到净值型产品，但是换汤不换药，在我看来，还是刚兑的，所以你如果去银行买理财产品，你想保本，如果极度厌恶风险就存定期或者买国债，大额的定期存款上浮后可以跟国债收益差不多，国债每个月都有买。当然银行自己的理财产品也是保本的，但是你首先要搞清楚，你买的是银行自己发行的理财产品，还是代销的。
 
其次买公募基金这些定投是可以的，但是也不要相信理财经理的推荐，他们也是韭菜。定投可能选个沪深300这种指数基金就好了。至于去银行买私募基金、或者信托产品这种，一般是私人银行的客户，风险接受能力比较强，也有一些认知能力，所以银行要做的就是把产品的特点介绍到位就可以了，让客户自己选择。
 
这里要说一下，银行自己的理财产品在资管新规实施前分保本和非保本，保本是体现在银行表内的，算做定期存款。非保本在表外，赚的是佣金。理财产品的投向分为标准化的市场，比如银行间债券市场或者二级市场股票定增等。还有就是非标，非标主要是基建和地产，其他还有一些产业基金之类的。另外，买理财都要做风险测评的，这个都是走过场，包括双录，双录就是监管层规定的录音录像，就是确认是你自己买的，知晓风险。
 
银行理财被喷的比较多的就是保险，很多老头老太太对银行理财没有概念的，然后理财经理销售保险产品的提成很高，所以一些无良的客户经理，就经常诱导老头老太，说这个收益高，然后还送点米啊油啊之类的，老头老太太一高兴就买了，后面子女发现了就来闹，但是保险产品提前退保，不但没有收益，还要扣费，所以经常会因为这种事情失去客户。
 
还有一个就是理财经理要完成新增贵宾客户指标，一般是让现在的客户帮忙介绍，或者组织一些活动吸引一些人参加。包括亲子活动啊，养生讲座啊，组织看房啊，反正是以客户需求为导向的。
 
理财经理暂时写这么多。其他像个贷客户经理，主要就是做一些个体工商户的经营性需求贷款，房屋按揭贷款。他们的做法一般是先铺点，也就是跟一些房屋中介之类的建立起联系，其他的就是跟对公客户经理搞好关系。捞到一笔开发贷，后续的按揭贷款就够吃几年的。银行的开发贷一般是绑定按揭贷的，所以会出现很多楼盘只支持某家银行的按揭贷款的现象。
 
另外信用卡管理员，就是负责整个支行的信用卡资料的整理，上交，因为银行的每个人都是有信用卡交表任务的，完成有奖励的。信用卡管理员一般不是银行的正式编制。包括信用卡的推销部门除了几个头头外也都不是正式编制。
 
但是分行的信用卡部门是正式编制，这个部门主要负责督导支行完成信用卡指标，另外还有就是跟商户洽谈合作，所以我们看到的一些行用卡的优惠打折活动，都是他们洽谈的。
 
银行的信用卡部门是很赚钱的，一般银行的信用卡有五十多天的免息期，所以很多朋友好奇银行白给钱是怎么赚钱的。这里有两个途径，一是、一般的信用卡刷够次数比如一年12笔都是没有年费的，但是你刷信用卡，商家是要给银行费用的，通常会有千三左右吧。
 
其次、就是分期，最低还款这些，通常日息是万五，是从消费日而不是还款日开始算。银行业内的人一般都知道招行的信用卡是最好用的，因为用的人越多，银行与商户谈判的空间越大，活动也越多，消费者得到的实惠也越多，一个用惯了招行信用卡的人很难再去用其他银行的信用卡，这就是转换成本，或者说护城河。
 
所以很多人上说银行是同质化经营的，是不了解银行，在快速发展阶段看不出差距，但是并不代表没有差距。银行的支行条线的运作基本就写到这里了，写的比较清楚了，从支行的经营可以窥见整个银行运营的全貌。
 
 
 
编辑于 2019-09-18
 
链接：https://www.zhihu.com/question/20204191/answer/48458121

1.两种查询引擎查询速度（myIsam 引擎 ）
 
InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行。
 
MyISAM只要简单的读出保存好的行数即可。
 
注意的是，当count(*)语句包含 where条件时，两种表的操作有些不同，InnoDB类型的表用count(*)或者count(主键)，加上where col 条件。其中col列是表的主键之外的其他具有唯一约束索引的列。这样查询时速度会很快。就是可以避免全表扫描。
 
总结：
 
mysql 在300万条数据（myisam引擎）情况下使用 count(*) 进行数据总数查询包含条件（正确设置索引）运行时间正常。对于经常进行读取的数据我们建议使用myIsam引擎。
 
 
 
2.百万数据下mysql分页问题
 
在开发过程中我们经常会使用分页，核心技术是使用limit进行数据的读取，在使用limit进行分页的测试过程中，得到以下数据：
 
select * from news order by id desc limit 0,10
耗时0.003秒
select * from news order by id desc limit 10000,10
耗时0.058秒
select * from news order by id desc limit 100000,10 
耗时0.575秒
select * from news order by id desc limit 1000000,10
耗时7.28秒
 
我们惊讶的发现mysql在数据量大的情况下分页起点越大查询速度越慢，100万条起的查询速度已经需要7秒钟。这是一个我们无法接受的数值！
 
改进方案 1
 
select * from news 
where id >  (select id from news order by id desc  limit 1000000, 1)
order by id desc 
limit 0,10
 
查询时间 0.365秒，提升效率是非常明显的！！原理是什么呢？？？
 
我们使用条件对id进行了筛选，在子查询 (select id from news order by id desc limit 1000000, 1) 中我们只查询了id这一个字段比起select * 或 select 多个字段 节省了大量的查询开销！
 
 
 
改进方案2
 
适合id连续的系统，速度极快！
 
select * from news 
where id  between 1000000 and 1000010 
order by id desc
 
不适合带有条件的、id不连续的查询。速度非常快！
 
3. 百万数据下mysql条件查询、分页查询的注意事项
 
接上一节，我们加上查询条件：
 
select id from news 
where cate = 1
order by id desc 
limit 500000 ,10 
 
查询时间 20 秒
 
好恐怖的速度！！利用第一节知识进行优化：
 
select * from news
where cate = 1 and id > (select id from news where cate = 1 order by id desc limit 500000,1 ) 
order by id desc 
limit 0,10 
 
查询时间 15 秒
 
优化效果不明显，条件带来的影响还是很大！在这样的情况下无论我们怎么去优化sql语句就无法解决运行效率问题。那么换个思路：建立一个索引表，只记录文章的id、分类信息，我们将文章内容这个大字段分割出去。
 
表 news2 [ 文章表 引擎 myisam 字符集 utf-8 ]
 
-------------------------------------------------
 
id int 11 主键自动增加
 
cate int 11 索引
 
在写入数据时将2张表同步，查询是则可以使用news2 来进行条件查询：
 
select * from news
where cate = 1 and id > (select id from news2 where cate = 1 order by id desc limit 500000,1 ) 
order by id desc 
limit 0,10
 
注意条件 id > 后面使用了news2 这张表！
 
运行时间 1.23秒，我们可以看到运行时间缩减了近20倍！！数据在10万左右是查询时间可以保持在0.5秒左右，是一个逐步接近我们能够容忍的值！
 
但是1秒对于服务器来说依然是一个不能接受的值！！还有什么可以优化的办法吗？？我们尝试了一个伟大的变化：
 
将 news2 的存储引擎改变为innodb，执行结果是惊人的！
 
select * from news
where cate = 1 and id > (select id from news2 where cate = 1 order by id desc limit 500000,1 ) 
order by id desc 
limit 0,10
 
只需要 0.2秒，非常棒的速度。
 
 
 
4.mysql存储引擎 myIsam和innodb的区别
 
MySQL有多种存储引擎，MyISAM和InnoDB是其中常用的两种。这里介绍关于这两种引擎的一些基本概念（非深入介绍）。
 
MyISAM存储引擎，基于传统的ISAM类型，支持全文搜索，但不是事务安全的，而且不支持外键。每张MyISAM表存放在三个文件中：frm 文件存放表格定义；数据文件是MYD (MYData)；索引文件是MYI (MYIndex)。
 
InnoDB是事务型引擎，支持回滚、崩溃恢复能力、多版本并发控制、ACID事务，支持行级锁定（InnoDB表的行锁不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，如like操作时的SQL语句），以及提供与Oracle类型一致的不加锁读取方式。InnoDB存储它的表和索引在一个表空间中，表空间可以包含数个文件。
 
核心区别
 
MyISAM是非事务安全型的，而InnoDB是事务安全型的。
 
MyISAM锁的粒度是表级，而InnoDB支持行级锁定。
 
MyISAM支持全文类型索引，而InnoDB不支持全文索引。
 
MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
 
MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。
 
InnoDB表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表（alter table tablename type=innodb）。
 
应用场景
 
MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
 
InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。
 
Mysql的存储引擎和索引
 
数据库必须有索引，没有索引则检索过程变成了顺序查找，O(n)的时间复杂度几乎是不能忍受的。我们非常容易想象出一个只有单关键字组成的表如何使用B+树进行索引，只要将关键字存储到树的节点即可。当数据库一条记录里包含多个字段时，一棵B+树就只能存储主键，如果检索的是非主键字段，则主键索引失去作用，又变成顺序查找了。这时应该在第二个要检索的列上建立第二套索引。 这个索引由独立的B+树来组织。有两种常见的方法可以解决多个B+树访问同一套表数据的问题，一种叫做聚簇索引（clustered index ），一种叫做非聚簇索引（secondary index）。这两个名字虽然都叫做索引，但这并不是一种单独的索引类型，而是一种数据存储方式。对于聚簇索引存储来说，行数据和主键B+树存储在一起，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说，主键B+树在叶子节点存储指向真正数据行的指针，而非主键。
 
InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。
 
MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。
 
为了更形象说明这两种索引的区别，我们假想一个表如下图存储了4行数据。其中Id作为主索引，Name作为辅助索引。图示清晰的显示了聚簇索引和非聚簇索引的差异。
 
 
 
我们重点关注聚簇索引，看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？
 
1 由于行数据和叶子节点存储在一起，这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。
 
2 辅助索引使用主键作为"指针" 而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置（实现中通过16K的Page来定位，后面会涉及）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。
 
所以在百万级数据及更大数据情况下，mysql innoDB 的索引表现更加优秀！
 
 
 
5、MySQL性能优化的一些经验
 
a.为查询优化你的查询
 
大多数的MySQL服务器都开启了查询缓存。这是提高性能最有效的方法之一，而且这是被MySQL的数据库引擎处理的。当有很多相同的查询被执行了多次的时候，这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不用操作表而直接访问缓存结果了。
 
这里最主要的问题是，对于程序员来说，这个事情是很容易被忽略的。因为，我们某些查询语句会让MySQL不使用缓存。
 
请看下面的示例：
 
// 查询缓存不开启
 
$r = mysql_query("SELECT username FROM user WHERE     signup_date >= CURDATE()");
 
// 开启查询缓存
 
$today = date("Y-m-d");
 
$r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");
 
上面两条SQL语句的差别就是 CURDATE() ，MySQL的查询缓存对这个函数不起作用。所以，像 NOW() 和 RAND() 或是其它的诸如此类的SQL函数都不会开启查询缓存，因为这些函数的返回是会不定的易变的。所以，你所需要的就是用一个变量来代替MySQL的函数，从而开启缓存。
 
 
 
b.学会使用EXPLAIN
 
使用EXPLAIN关键字可以让你知道MySQL是如何处理你的SQL语句的。
 
select id, title, cate from news where cate = 1
 
发现查询缓慢，然后在cate字段上增加索引，则会加快查询
 
 
 
c.当只要一行数据时使用LIMIT 1
 
当你查询表的有些时候只需要一条数据，请使用 limit 1。
 
 
 
d.正确的使用索引
 
索引并不一定就是给主键或是唯一的字段。如果在你的表中，有某个字段你总要会经常用来做搜索、拍下、条件，那么，请为其建立索引吧。
 
 
 
e.不要ORDER BY RAND()
 
效率很低的一种随机查询。
 
 
 
f.避免SELECT *
 
从数据库里读出越多的数据，那么查询就会变得越慢。并且，如果你的数据库服务器和WEB服务器是两台独立的服务器的话，这还会增加网络传输的负载。必须应该养成一个需要什么就取什么的好的习惯。
 
 
 
g.使用 ENUM 而不是 VARCHAR
 
ENUM 类型是非常快和紧凑的。在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这样一来，用这个字段来做一些选项列表变得相当的完美。
 
如果你有一个字段，比如“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。
 
 
 
h.使用 NOT NULL
 
除非你有一个很特别的原因去使用 NULL 值，你应该总是让你的字段保持 NOT NULL。这看起来好像有点争议，请往下看。
 
首先，问问你自己“Empty”和“NULL”有多大的区别（如果是INT，那就是0和NULL）？如果你觉得它们之间没有什么区别，那么你就不要使用NULL。（你知道吗？在 Oracle 里，NULL 和 Empty 的字符串是一样的！)
 
不要以为 NULL 不需要空间，其需要额外的空间，并且，在你进行比较的时候，你的程序会更复杂。 当然，这里并不是说你就不能使用NULL了，现实情况是很复杂的，依然会有些情况下，你需要使用NULL值。
 
 
 
下面摘自MySQL自己的文档
 
“NULL columns require additional space in the row to record whether their values are NULL. For MyISAM tables, each NULL column takes one bit extra, rounded up to the nearest byte.”
 
i.IP地址存成 UNSIGNED INT
 
很多程序员都会创建一个 VARCHAR(15) 字段来存放字符串形式的IP而不是整形的IP。如果你用整形来存放，只需要4个字节，并且你可以有定长的字段。而且，这会为你带来查询上的优势，尤其是当你需要使用这样的WHERE条件：IP between ip1 and ip2。
 
我们必需要使用UNSIGNED INT，因为 IP地址会使用整个32位的无符号整形
 
 
 
j.固定长度的表会更快
 
如果表中的所有字段都是“固定长度”的，整个表会被认为是 “static” 或 “fixed-length”。 例如，表中没有如下类型的字段： VARCHAR，TEXT，BLOB。只要你包括了其中一个这些字段，那么这个表就不是“固定长度静态表”了，这样，MySQL 引擎会用另一种方法来处理。
 
固定长度的表会提高性能，因为MySQL搜寻得会更快一些，因为这些固定的长度是很容易计算下一个数据的偏移量的，所以读取的自然也会很快。而如果字段不是定长的，那么，每一次要找下一条的话，需要程序找到主键。
 
并且，固定长度的表也更容易被缓存和重建。不过，唯一的副作用是，固定长度的字段会浪费一些空间，因为定长的字段无论你用不用，他都是要分配那么多的空间。
 
 
 
k.垂直分割
 
“垂直分割”是一种把数据库中的表按列变成几张表的方法，这样可以降低表的复杂度和字段的数目，从而达到优化的目的。需要注意的是，这些被分出去的字段所形成的表，你不会经常性地去Join他们，不然的话，这样的性能会比不分割时还要差，而且，会是极数级的下降。
 
 
 
l.拆分大的 DELETE 或 INSERT 语句
 
如果在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。
 
Apache 会有很多的子进程或线程。所以，其工作起来相当有效率，而我们的服务器也不希望有太多的子进程，线程和数据库链接，这是极大的占服务器资源的事情，尤其是内存。
 
如果你把你的表锁上一段时间，比如30秒钟，那么对于一个有很高访问量的站点来说，这30秒所积累的访问进程/线程，数据库链接，打开的文件数，可能不仅仅会让你泊WEB服务Crash，还可能会让你的整台服务器马上掛了。
 
 
 
m.越小的列会越快
 
对于大多数的数据库引擎来说，硬盘操作可能是最重大的瓶颈。所以，把你的数据变得紧凑会对这种情况非常有帮助，因为这减少了对硬盘的访问。
 
 
 
n.选择正确的存储引擎
 
在 MySQL 中有两个存储引擎 MyISAM 和 InnoDB，每个引擎都有利有弊。
 
MyISAM 适合于一些需要大量查询的应用，但其对于有大量写操作并不是很好。甚至你只是需要update一个字段，整个表都会被锁起来，而别的进程，就算是读进程都无法操作直到读操作完成。另外，MyISAM 对于 SELECT COUNT(*) 这类的计算是超快无比的。
 
InnoDB 的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比 MyISAM 还慢。他是它支持“行锁” ，于是在写操作比较多的时候，会更优秀。并且，他还支持更多的高级应用，比如：事务。
 
转自：https://www.cnblogs.com/llzhang123/p/9239682.html

@日常命令
 
 
@命令速查
 
 
@更多查找
 
 
@系统管理
 
 
@软件安装
 
 
@文本命令
 
 
@管道与重定向
 
 
 
@压缩和解压
 
 
@磁盘管理
 
 
@登录日志
 
 
@用户与权限
 
 
/etc/passwd文件说明：
 
是用户管理工作涉及的最重要的一个文件
内容包含7个字段，例如 him:x:200:50:Sam san:/usr/sam:/bin/sh
含义分别为 用户名:口令:用户标识号:组标识号:注释性描述:主目录:登录Shell
@网络管理
 
 
@远程登录
 
 
如果远程持有自己的公钥后依然无法免密登录，需要修改配置文件，请参考： https://blog.csdn.net/b_x_p/article/details/78534423
 
@进程管理
 
 
@服务管理
 
 
 
@其它命令
 
 
@一键安装Ubuntu常用库