zabbix前端效率极低，大批量更新会造成Oracle tx锁，因此对于大批量更新，会选择用sql直接update。当然也可以用其他方式，比如通过PHP代码来解决等等。
但是在现有条件下，直接跑sql肯定会比其他方式方便很多，其他方式需要通过代码调用zabbix API来实现。个人觉得在保证数据库正常完成生产需求的情况下，一些
批量增、删、改、查通过sql直接跑库是很不错的。当然了，你要用sql去操作zabbix数据库，必须要对zabbix数据表结构有清晰的了解才行。
还有一种情况，zabbix收集了大量的裸数据，其他人可以通过这些数据进行相关的分析，这个时候拿这些数据也需要对zabbix数据库结构了解才行。
目前没有看到成型的教程文档类的东西来指导我们了解zabbix数据库结构，从网上搜了很多相关的文档零零散散，最后经过测试、验证总结出来此文。算是一种对
zabbix、数据库知识的一个深度学习加复习吧。废话不多讲，直奔主题。
须知
zabbix数据库中的表的名称都是复数，比如存放Host信息的表名字是Hosts等。这些可以直接从数据库中看到。
数据库操作有风险，一旦出现问题会造成zabbix crash，因此操作需谨慎
普通的查询可以在备库上进行，数据时同步的。满足查询需求的同时，也不对因为查询影响生产性能。
表结构概述
zabbix的数据库设计很有特点，针对zabbix中的每一个资源，都有一张表与其对应，比如hosts表、items表等。而每一张表中都有一个id字段。资源之间的关联关系是
通过外键来完成的。比如host和item的关联关系，就是在items表中用hostid与hosts表中的资源进行关联的。
下面以hostid举例说明，其他itemid、triggerid等都类似。
hostid是每一个host的唯一标识，我们从数据库查询时，一般都是以hostid为查询条件。
我们点开一个host，看其URL：http://192.168.232.130/zabbix/hosts.php?form=update&hostid=10084&groupid=0&sid=07d1c2806378f190
我们可以看到URL里的Get参数：
1、from：标识当前页面的操作，这里的update是因为我是从Configuration-Hosts中点击host进去的，所以是一个更新操作
2、hostid：点击的host的hostid
3、groupid：这里不需要groupid这个字段，因此这个0没有意义
4、sid：sessionid，标识用户用的
zabbix前端界面的URL有很多像上面的URL那样。有的是itemid，有的是triggerid，我们更改一下这个id，就自然能够跳到对应的界面了。这一点正是zabbix的
灵活之处。
Hosts表
"Host"就是指一台被监控的机器。先看下Hosts表结构：
- hostid：唯一标识Host在zabbix及数据库的id。不同表之间的关联也用hostid。和这个类似，zabbix中任意一种资源都有自己的id，比如itemid，groupid等。
- proxy_hostid：如果使用"proxy_server"架构，这个字段表示的是监控这台机器的proxy的hostid。此处有一点需要注意，每个proxy在hosts表里有两条记录
一条是和普通机器一样的、作为被监控机器的记录；另一条是作为proxy的。作为proxy的那条记录，IP字段的值为"0.0.0.0"。proxy_hostid中的值就是proxy
proxy记录中的hostid。 - host：机器的hostname。
- dns：DNS名称
- useip：是否用IP监控
- port：监控使用的端口
- status：机器目前的状态。"0"为正常监控，"1"为disable。"2"不清楚，从数据库里找不到status为"2"的机器。Google后，这个好像是zabbix自身的一个host
available检查有关。"3"表示是个Template - disable_util，error，available，errors_from(ipmi_disable_util，ipmi_error...)：这几个都是zabbix poller会去修改的值。当poller在第一次取不到值(根据
值得类型不同会更新相应的列，item类型为snmp就会更新snmp_XXX，默认为zabbix类型)的时候，会等待15s(CONFIG_UNREACHABLE_DELAY)重试，如果
15s后依然取不到值，zabbix会在数据库更新这个host取不到值得信息。而且日志里显示"another network error" - lastaccess：这一列是专门为proxy准备的。lastaccess表示的是proxy最后一次工作的时间。此处的工作是指zabbix server收到proxy数据
- inbytes，outbytes：
- useipmi，ipmi_*:
- snmp_*:
- maintenanceid,maintenance_*:这个是zabbix另一个机制Maintenance有关，用来将host置于维护状态而不会报警
常用操作
更新机器的proxy。找到proxy的hostid，更新对应host的proxy_hostid：
select hostid from hosts where host=' '; #get：hostid,proxy的
update hosts set proxy_hostid=' ' where host='';
update hosts set status='0' where host='';
update hosts set status='1' where host='';
Items表
items表也是zabbix的核心表之一，它记录了item的所有设置。大家都知道，在zabbix中做的最多的操作就是对于items了，下面我们看下items表结构：
- itemid：item的id
- type：item的type，和前端配置item的type对应。数据库中这一列的值是0-17的数字，分别代表：
0：zabbix agent
1：SNMPv1 agent
2：zabbix trapper
3：simple check
4：SNMPv2 agent
5：zabbix internal
6：SNMPv3 agent
7：zabbix agent(active)
8：zabbix aggregate
9：web item
10：external check
11：database monitor
12：IPMI agent
13：SSH agent
14：TELNET agent
15：calculate
16：JMX agent
17：SNMP trap - snmp_community：
- snmp_old：
- hostid：item所在的host的hostid。如果该item属于template，那么这里显示的是templateid
- name：item的名字
- key_：item的key
- delay：这里的delay，实际就是在配置item时候配置的"Update Interval"
- history：前端配置中的存储history的时间
- trends：前端配置中的存储trend的时间
- status：item的状态
0：item是enable状态
1：item是disable状态 - value_type：item返回值的类型
0：numeric float
1：character
2：log
3：numeric unsigned
4：text - trapper_hosts：
- units：
- multiplier：
- delta：
- snmpv3_securityname：
- snmpv3_securitylevel：
- snmpv3_authpassphrase：
- snmpv3_privpassphrase：
- formula
- error：item的错误信息
- lastlogsize：
- logtimefmt：
- templateid：
- valuemapid：
- delay_flex：
- params：
- ipmi_sensor：
- data_type：
- authtype：
- username：
- password：
- publickey：
- privatekey：
- mtime：
- flags：
- filter：
- interfaceid：
- port：
- description：
- inventory_link：
- lifetime：
- snmpv3_authprotocol：
- snmpv3_privprotocol：
- state：当前item的状态
0：正常
1：not supported - snmpv3_contextname：
Trigger表结构
Trigger是zabbix的重要部分，平时工作中除了host和item，就属trigger了。而且trigger相对于host和item来说
更加复杂。host和item在数据库中对应的hosts表和items表都是非常平面的表，结构简单，host和item的属性在
表中一目了然。而trigger在数据库中对应的triggers表则相对复杂，它和其他表的关联关系很强，需要仔细分析。
先看下triggers表结构：
下面我们从前端找一个trigger来看下：
这个trigger的URL：http://192.168.153.130/zabbix/triggers.php?form=update&hostid=10084&triggerid=13491&sid=a8af27a7c7b0697b
从URL中我们可以看到起triggerid为13491，那么我们根据triggerid从数据库中取一下这个trigger：
sql：select * from triggers where triggerid=13491\G
现在可以明白triggers里边主要字段的作用了吧。trigger的核心是expression，也就是我们定义trigger的逻辑是：{192.168.153.130:agent.ping.nodata(5m)}=1
，但是数据库里没有这个东西，只有一个{12900}=1。1是那个阈值，那么这个{12900}又是什么鬼东西呢？根据前端trigger来看，这个逻辑的属性是"Expressions"
的内容，我们先查一下数据库中expressions表记录的内容：
这不是trigger里的expression，而是Administration-General里的"Regular expressions"，从前端看：
那这个{12900}究竟是什么呢？原来是function，内容在functions表：
sql：select * from functions where functionid=12900;
对应trigger的expression，一目了然。
Events表
大家都知道，当zabbix server获取到一个数据，它会检查跟这个item相关的trigger，然后无论是否出发action，都会生成一个event。events表结构：
- source：event可能由多种源头生成，这里的source是记录了这个event是由什么事件生成的
0：由trigger生成的event
1：由discovery rule生成的event
2：由agent auto-registration生成的event
3：internal的event - object：这个字段记录了和event关联的zabbix对象
对于trigger相关联的events，这里的值只可能是0
对于discovery相关的event，"1"表示是discovered host;"2"表示是discovered service
对于auto-registration的event，这里值一定是"3"
对于interval的event，"0"表示trigger，"4"表示item，"5"表示low-level discovery - objectid：根据前面object里的定义，这里可能为triggerid，也可能是discovered hostid
- value：和object字段类似，根据source不同，这里的值有不同的含义
对于trigger类型的event：
0：trigger的状态位OK
1：trigger的状态位problem
对于discovery类型的event：
0：host或service正在工作
1：host或service停止工作
2：host或service被侦测到
3：host或service丢失了
对于internal类型的event：
0：normal状态
1：unknown或者not supported状态
History和Trends
History和Trends都是存储历史数据的地方，但是他们究竟有什么区别，现在我们从数据库入手看一下这个问题。
首先我们看数据库中history和trends相关的表：
sql：show tables like '%history%';
sql:show tables like '%trends%';
trends表是比较简单的，共两个表，其中trends_unit表示的是unsigned int，这两张表功能是一样的，只是存储
的数据类型不同。
history表就比较多了，单从表名来看，我们能够很清楚的看到，大多数history表只是分了不同的数据类型，比如str
表示字符串，log表示log文件类型。其中有个synv这个属性，大家都知道sync一般是"synchronize"的缩写，在这里
带有sync后缀的history表，是用作Master-Child同步数据用的。
那么history和trends表的区别呢
它们的相同点是都是存储历史数据的，不同点是他们存储数据的粒度不同。每一次zabbix接收到item数据后，会将其
存入history表。下面是history表结构：
sql：desc history;
这个是很简单的结构，clock和ns保存着接收item的时间，itemid唯一标识了item，value即为接收到的数据。
而trend表的作用是将history表的数据根据小时的维度进行归档。它会针对每一个itemid，计算每个小时的最小值，
最大值和平均值，下面是trends表结构：
sql：desc trends;
num字段表示了该小时使用了多少数据来计算最小值、最大值和平均值。
housekeeper和trends表
history表的作用我们已经清楚了，就是存储所有item的历史数据。衡量zabbix性能有一个重要指标，就是vps--Value Per Second。
如果vps为1000的时候，即每秒zabbix要处理1000个数据，每一个数据都会在history表中有一行，现在计算一下，一天有86400秒，
每秒1000行数据，那么一天就是86400000行，8千万行！如果一直这样无限制膨胀下去，history表的性能会很差，从而拖累整个
zabbix数据库的性能。
应对这个问题，zabbix提供了两方面的解决办法，一个是housekeeper机制，另一个则是trends机制。
housekeeper非常简单，就是定期删除history表中的数据。对于小规模的zabbix来说，这是个省时省力的方法，但对于大规模的zabbix
数据库，但对于大规模的zabbix数据库，使用housekeeper效率非常差，特别是InnoDB引擎的MySQL，因为大表的删除非常慢。对于
规模很大的zabbix，我觉得应该每周truncate一次history相关的表，大家可能会担心这么暴力的删除会不会影响数据完整性，我们来看下
trends表的作用，就明白了。
trends表的工作原理大家都清楚了。这里我们看下trends在zabbix的用处。其实在zabbix中，trends只在很少几个地方出现，最重要的
就是在Graph中了，我们看某个时间点，图中其实有3个数据。从小到大分别是这个时间点的最小值、平均值和最大值。这里调用的就是
trends表的数据。大家想一下，history的数据真的有必要保存那么久吗？对于上周的数据，我们要精确到每一分钟吗？并不需要，对于
时间越久的数据，我们需要的粒度就更粗。
Graph对于history和trends的选择
我们来分析下Graph选择从history表选数据还是从trends选
https://wenku.baidu.com/view/8d56c7b489eb172ded63b7ea.html