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: 
> 
> When MySQL updates the index due to an insert, does it rebuild the
>  entire index?
> 
> 
> 

No, MySQL doesn't "rebuild" the index on each insert.

MySQL's default page size is 16K. It allocates these pages in 1MB increments (called extents).

When a table is first created (indexes are rebuilt), the pages are filled up 15/16th full, leaving room for some random inserts. If your index entries are 500 bytes each each (primary key size + row data for a clustered index), that leaves room for 2 new rows to be inserted before having to split the page.

When MySQL needs to insert a row on a full page, the page must be split. MySQL will add a new page, and move half of the page data to the new page.

Within a page, records may not actually be in physical order. They'll be in the order they were inserted. They're linked in order via a form of linked list. So, even a random insert doesn't cause data to be physically reordered. Outside the need to split a page, the data isn't moved around.

After may random inserts, your pages will be from 1/2 full to full.

All of this work does affect your insert performance, as the index must be updated with each insert. In addition, an index with many half full pages will negatively affect read performance.

Now, if you're inserting rows in index order, then MySQL simply keeps adding to the end of the pages, filling them up 15/16 full, and adding an extent at a time of pages. Much less performance penalty since there is no splitting of pages, hence no moving of data is involved, not to mention the read performance benefit of nearly full pages.

So, while there is some maintenance involved in updating an index for inserts, MySQL isn't "rebuilding" the index on each insert. Also, see Bill Karwin's [note about change buffering](https://stackoverflow.com/a/23435759/168493), which may affect you.
Note that MariaDB, which you are probably using if you apt install mysql on a modern system, removed the buffering mentioned in the accepted answer.

> 
> The change buffer has been disabled by default [in updates to] MariaDB 10.5, 10.6, 10.7, and 10.8, and the feature is deprecated and ignored from MariaDB 10.9.0.  
> 
> Benchmarks show that the change buffer sometimes reduces performance, and **in the best case seem to bring a few per cent improvement to throughput**. However, [if untimely crashes occur] then the InnoDB system tablespace can grow out of control.
> 
> 
> 

Paraphrased from <https://mariadb.com/kb/en/innodb-change-buffering/>, emphasis mine.

Oracle's database server still has this feature in their documentation for the latest version: <https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer.html>