Question: Why when I am using javascript the basic HTML inputs validation not performed?  

Say the min max attributes.

Here the HTML:

```
<form action="#" method="get">Quantity (between 1 and 5):
    <input type="number" name="quantity" min="1" max="5">
    <br />
    <input type="submit" value="with HTML">
</form>
<button id="sender">with JS</button>

```

JS:

```
$("#sender").click(function (event) {
    $("form").submit();
});

```

And live example: <http://jsfiddle.net/txP4R/2/>

Answer: 
MySQL is probably already doing what you describe, as much as it can.

In the case of InnoDB (which should be your default storage engine with MySQL), inserts and updates and deletes change primary key or unique key indexes immediately. But they never rebuild the *whole* index, they add new values into (or take values out of) these indexes.

For non-unique indexes, InnoDB performs [change buffering](https://dev.mysql.com/doc/refman/en/innodb-change-buffer.html). That is, it queues the changes, which will be merged into the index later in the background. It will even consolidate changes so that the physical updates to the index are done more efficiently.

You don't have to do anything to enable this feature, because it's enabled by default. MySQL 5.1 does change buffering only for `INSERT`. MySQL 5.5 and later additionally does change buffering for `UPDATE` and `DELETE`.

You can *disable* this feature if you want (for instance if you use SSD, avoiding random I/O is not so important, and you might want to ensure that queued changes don't accumulate). Normally, you should keep the feature enabled.
MySQL doesn't "rebuild" the index after every insert. MySQL inserts one or more rows into an existing index.

MySQL has lots of unusual options, and I don't know all of them. I would be surprised if there were an option that said: "Oh, let the index on the table be out of synch with the data in the table." Doesn't sound reasonable.

If you have lots of inserts, the best strategy is to do the inserts in one statement. Instead of:

```
insert into t(...)
    select . . .
    from t2
    where id = id1;

```

Do:

```
insert into t(...)
    select . . .
    from t2
    where id in (id1, id2, . . .)

```

An extension on this is to insert into a temporary table. Then just load the temporary table into the big table all at once:

```
insert into t(...)
    select ...
    from temptable;

```

Finally, it is sometimes faster to drop indexes, do a big insert (in one or more steps), and then re-create the indexes.

One caution: if you drop unique indexes you are also dropping the unique constraint. This is important if you are using `on duplicate key update`, because it needs a secondary index to find the duplicate key (except for the primary key).