Unfortunately there's not enough information here to help you. Best bet is probably too just wipe everything and start the installation over again.

It shouldn't happen but it seemed to have happened before already: the problem is caused by a spammer registering already on your newly installed site before you have even created the admin account. Elgg fails then to correctly create the admin account.

As far as I remember there's an open issue about that at github. So, it will hopefully get fixed in a future version of Elgg. Right now, you can't do much though. I would suggest to repeat the installation from the beginning and hope that it works then.

If your server is under so heavy attacks that it is impossible to install Elgg even and add some anti-spam plugins (e.g. Spam Login Filter) afterwards, you might ask your hoster if there's anything possible to block the spammers. As workaround during installation of Elgg you could block all IPs but your own temporarily by adding a few lines to Elgg's .htaccess (howto at http://stackoverflow.com/questions/4400154/htaccess-deny-all-allow-only-one-ip). Of course, you would have to remove these lines again once you've set up your site.

It could be the log table and possibly also archived but not deleted backups of the log table created by the Logrotate plugin.

Best would be to check the size of the tables for example in phpMyAdmin to see which tables are large. If it's not the log tables, there might be an issue resulting in some other table being larger than normal.

What version of Elgg are you using? And do you have the cronjobs of Elgg configured and then also the bundled Garbagecollector and Logrotate enabled and configured. These plugins will clean up the database regularly resulting in a smaller database (if the reason for the large size isn't some issue/bug not covered by these plugins). On newer versions of Elgg the Logrotate plugin also has the option to delete archived log tables older than the configured time automatically to reduce database size. Maybe best would be to just set up this option and let Elgg do the job of deleting older logs. Otherwise, you still could delete the tables of archived logs yourself (but do not delete the current log table!).

newest version .... I drop all now ,no time  check which table cause the issue also, I guess the log should be write in file but database

It's the logging of database operations only that are saved in the database. And if you don't check the size of your database tables you wouldn't even know if it's the log table that got so large.

Why not check which table is large? This could be done surely faster than setting up again the whole site from start. And depending on what causes the database getting so large the same could happen again with the new installation. If it's just the log that got so large you would only have to set up the cronjobs and Logrotate plugin and it gets sorted out automatically.