本文章只针对从mysql随机抽取数据进行方法分析，和总结

项目需要通过表名获取随机数据进行数据校验工作，所以有这个随机从数据库拉数据的需求；

通过查询资料和网友们的博客等都未能很好解决需求问题，接下来针对网上的方法进行分析和总结，并给出自己最优的解决方案；
直接进入主题：
mysql随机抽取数据方法汇总
1.第一种：
select * from `table`
order by rand() limit 1;

分析：该种抽取数据的方法，可以达到效果，但是运行效率非常低，在百万级别下运行时间超长，无法满足需求。
2.第二种：
SELECT *
FROM `table` AS t1 JOIN (SELECT ROUND(RAND() * (
(SELECT MAX(id) FROM `table`)-(SELECT MIN(id) FROM `table`))+(SELECT MIN(id) FROM `table`)) AS id) AS t2
WHERE t1.id >= t2.id
ORDER BY t1.id LIMIT 1;

分析：该种方法相比第一种效率非常高，基本在0.几秒内能查询获取到的数据

优点：速度非常快，在千万级数据下，随机查询获取一条数据的时间为0.161s；

缺点：无法一次性获取多条，当把limit改写成10000之后，获取到的数据是连续的，无法满足需要的随机性。
3.第三种：
SELECT * FROM `table` WHERE id >= (ROUND(((( SELECT MAX( id ) FROM `table`)-( SELECT MIN( id ) FROM `table`)) * RAND()),0) + ( SELECT MIN( id ) FROM `table`))
LIMIT 1;

分析：该种方法相比于第一种方法效率非常高，跟第二种方法执行效率差不多；能基本满足随机性要求，但是当将limit 改成100或者10000的时候，数据出现连续一段范围内的随机数，而不是全量数据里面的随机。

优点：速度非常快，在千万级数据下，随机查询一条的时间为0.116s,能获取随机性多条数据；另外当数据的ID不连续之后，通过该方法能一次性获取200；数据库会自动排除不存在的ID；

缺点：在数据量达千万级别时，limit变成10000之后，数据还是随机的，但是会相对性的限制在一定范围内，当limit改成200之后，ID随机性保存在1-100000之间的随机性，达不到需求的全量随机性；导致该问题的原因在rand()函数；但是当我将最多id和最小id取出来自己做了操作之后，查询效率变慢了 ；
4.第四种：
采用程序生成随机ID，并查询获取的方式

具体方法：

①：通过表名获取最大ID和最小ID值

②：生成随机数方法：
public class NumberUtil {

    public static void main(String[] args) {
        //0-10之内,随机取五个数
        List<Integer> integers = randomCommon(1, 1496255, 200);
        if (integers != null && integers.size() != 0) {
            for (int i : integers) {
                System.out.println(i + ",");
            }
        } else {
            System.out.println("kk");
        }
    }

    /**
     * 随机指定范围内N个不重复的数
     *
     * @param min 指定范围最小值
     * @param max 指定范围最大值
     * @param n   随机数个数
     * @return
     */
    public static List<Integer> randomCommon(int min, int max, int n) {
        List<Integer> integers = new ArrayList<Integer>();
        if (min < 0) {
            min = 0;
        }
        if ((max - min) + 1 < n) {
            n = (max - min) + 1;
        }
        if (max < min) {
            max = min;
        }
        if (max < 0 || n < 0) {
            return integers;
        }
        for (int i = 1; i <= n; i++) {
            int randomNumber = (int) Math.round(Math.random() * (max - min) + min);
            if (integers.contains(randomNumber)) {
                i--;
                continue;
            } else {
                integers.add(randomNumber);
            }
        }
        return integers;
    }
}

③：通过获取到的ID，进行数据查询，在该方法内为了避免数据ID不连续问题，当中有两种方法可选：

第一种：通过上述第三种方法进行数据获取；

第二种：通过扩大随机范围获取数据，在从获取到的数据，在通过中位数从中间往两端获取数据达到随机数据的需去，部分代码如下：



通过以上步骤满足项目需求，如果只对一张table进行数据随机获取，该方法效率还算可观；

当需要对N张table进行数据获取操作，则可以通过stream.parallelStream并发进行获取数据，有兴趣的可以自行进行查找资料学习一下，在要获取N张table表的随机数据的时候，则会涉及到多个库的操作，在建立连接会消耗一定的时间，效率还是会有所降低的。但是整体效果还是不错的哦。该需求完成处理解决。
。。

。。

。。
有不同见解的同学，也可以进行反馈；

最近做的几个项目，都碰到了ODI从oracle9i或者10g数据库中抽取增量数据的情况，那么ODI如何从数据库中抽取增量数据呢，ODI针对Oracle数据库的抽取，提供了3类知识模块：
Oracle Simple
Oracle Consistent
Oracle 9i/10g/11gConsistent (LOGMINER)
Simple方式一般是针对数据库中需要增量复制的表之间没有主外键约束的情况，在这种方式下，表之间的先后复制关系没有影响。但如果表之间有主外键对照关系，采用simple方式就会出现问题，举个简单的例子，我们需要从源数据库抽取两张表订单和订单明细表的增量数据，其中订单明细表的外键要参照订单表的主键。
1.      我们将订单表中主键从11000-25000的增量数据复制到目标端。
2.      在复制的过程中，源端订单表又插入了两条新数据，主键为25001和25002。
3.      当进行订单明细表的增量数据复制时，与订单表中主键25001和25002对应的明细数据就会在目标端出错，因为刚才复制时，这两条数据没有复制到目标端。
Consistent方式就是专门来解决这个问题的，它在处理父表前首先锁定（注意不是锁住）主表和子表需要复制的记录，在增量数据复制时，插入主表和子表的新增量数据都会被本次抽取过程忽略，放在下次抽取时处理。因此采用Consistent方式进行增量数据捕获一般需要5个步骤：
1.      扩展窗口（extend_window）:计算主表和子表本次抽取的结果集，并赋予其一个序列号。
2.      锁定订阅者（lock subscriber）：针对变化数据的某个订阅者，确定其需要抽取的序列号范围（一个系统的变化数据可能会被多个系统使用，比如主数据管理系统）。
3.      执行抽取过程，我们通过ODI中的接口程序进行实现。
4.      抽取完成后，解锁订阅者（unlock subscriber）：记录下本次抽取的最后的序列号，以便于下次使用。
5.      清除增量数据（Purge the journal）：将已经复制完成的增量数据清楚（这里是指所有的订阅者）。
 
在具体的实现方式上，Oracle Simple、Oracle Consistent是采用同步方式进行增量数据抽取的，说白了就是在源系统相关表上添加触发器，如下图所示：

 
 

当源数据库中的交易需要修改相关表时，会调用触发器，将变化数据插入到增量表中，触发器的调用是包含在交易中的，这就决定了变化数据的实时性高，在需要实时变化的场景，非常适用，而且这种方式在数据库非归档状态下也照常运行，其缺点是由于触发器包含在对数据修改的事务中，当系统并发量比较大时，会对原有系统的效率产生一定影响。很多同事一听说触发器就觉得对源系统影响非常大，其实并不是这样。这里需要澄清的一点概念是触发器往变化数据表中写的并不是所有变化的数据，而可能只是一个主键或者再加一点额外的信息，其对系统的影响比我们想象的要小得多。
Oracle 9i/10g/11gConsistent (LOGMINER)方式可以配置成异步方式，基于Oracle数据库的online redo log进行变化数据的捕捉（这里要特别提醒的是目前ODI只支持Hotlog方式），说的更白一点就是oracle stream技术，变化的数据通过logminer技术从在线日志中获取。如下图所示：
 


这种方式基于异步的策略，一般变化数据的获取会有1秒到几分钟的数据延迟，当然对数据仓库系统来讲，这点时间也不算啥。但是由于其从日志中抽取变化数据，对原有的生产系统影响很小，而且该方式在用户原来的schema上除了一个读权限外，不需要额外的权限要求，因此大多数用户都愿意采用这种方式。但该方式需要对用户有一定的权限要求，而且数据库必须运行在归档模式下。具体的配置我们下次再说。
 

最近做的几个项目，都碰到了ODI从oracle9i或者10g数据库中抽取增量数据的情况，那么ODI如何从数据库中抽取增量数据呢，ODI针对Oracle数据库的抽取，提供了3类知识模块：
Oracle Simple
Oracle Consistent
Oracle 9i/10g/11gConsistent (LOGMINER)
Simple方式一般是针对数据库中需要增量复制的表之间没有主外键约束的情况，在这种方式下，表之间的先后复制关系没有影响。但如果表之间有主外键对照关系，采用simple方式就会出现问题，举个简单的例子，我们需要从源数据库抽取两张表订单和订单明细表的增量数据，其中订单明细表的外键要参照订单表的主键。
1.      我们将订单表中主键从11000-25000的增量数据复制到目标端。
2.      在复制的过程中，源端订单表又插入了两条新数据，主键为25001和25002。
3.      当进行订单明细表的增量数据复制时，与订单表中主键25001和25002对应的明细数据就会在目标端出错，因为刚才复制时，这两条数据没有复制到目标端。
Consistent方式就是专门来解决这个问题的，它在处理父表前首先锁定（注意不是锁住）主表和子表需要复制的记录，在增量数据复制时，插入主表和子表的新增量数据都会被本次抽取过程忽略，放在下次抽取时处理。因此采用Consistent方式进行增量数据捕获一般需要5个步骤：
1.      扩展窗口（extend_window）:计算主表和子表本次抽取的结果集，并赋予其一个序列号。
2.      锁定订阅者（lock subscriber）：针对变化数据的某个订阅者，确定其需要抽取的序列号范围（一个系统的变化数据可能会被多个系统使用，比如主数据管理系统）。
3.      执行抽取过程，我们通过ODI中的接口程序进行实现。
4.      抽取完成后，解锁订阅者（unlock subscriber）：记录下本次抽取的最后的序列号，以便于下次使用。
5.      清除增量数据（Purge the journal）：将已经复制完成的增量数据清楚（这里是指所有的订阅者）。
 
在具体的实现方式上，Oracle Simple、Oracle Consistent是采用同步方式进行增量数据抽取的，说白了就是在源系统相关表上添加触发器，如下图所示：

 

当源数据库中的交易需要修改相关表时，会调用触发器，将变化数据插入到增量表中，触发器的调用是包含在交易中的，这就决定了变化数据的实时性高，在需要实时变化的场景，非常适用，而且这种方式在数据库非归档状态下也照常运行，其缺点是由于触发器包含在对数据修改的事务中，当系统并发量比较大时，会对原有系统的效率产生一定影响。很多同事一听说触发器就觉得对源系统影响非常大，其实并不是这样。这里需要澄清的一点概念是触发器往变化数据表中写的并不是所有变化的数据，而可能只是一个主键或者再加一点额外的信息，其对系统的影响比我们想象的要小得多。
Oracle 9i/10g/11gConsistent (LOGMINER)方式可以配置成异步方式，基于Oracle数据库的online redo log进行变化数据的捕捉（这里要特别提醒的是目前ODI只支持Hotlog方式），说的更白一点就是oracle stream技术，变化的数据通过logminer技术从在线日志中获取。如下图所示：
 


这种方式基于异步的策略，一般变化数据的获取会有1秒到几分钟的数据延迟，当然对数据仓库系统来讲，这点时间也不算啥。但是由于其从日志中抽取变化数据，对原有的生产系统影响很小，而且该方式在用户原来的schema上除了一个读权限外，不需要额外的权限要求，因此大多数用户都愿意采用这种方式。但该方式需要对用户有一定的权限要求，而且数据库必须运行在归档模式下。具体的配置我们下次再说。

order('rand() asc')