we have a SharePoint 2010 farm and sql instance for this farm in a sql farm, and if create non-SharePoint related databases in same instance for SharePoint farm,
is any danger / issues to SharePoint?
if it is any issues how it came?
The answer is 'it depends'. While throwing memory at it may work, there are other factors to consider, such as CPU usage, Disk I/O, and Network I/O. There are also backup and restore strategies to consider. But all of this depends on your existing usage of your SharePoint databases as well as the future usage of these non-SharePoint databases. This is not something we can directly answer as we do not have that information nor access to measure the performance of your existing environment.
As per the Best Practices from MSFT:
To ensure optimal performance for farm operations, we recommend that you install SQL Server 2008 R2 with SP1 or SQL Server 2012 on a dedicated server that does not run other farm roles and does not host databases for other applications.
We had an issue in past where host two SharePoint farm's database on single SQL server and performance really hurt us. After Working with MSFT, we split the database to two sql server.
Again its depend upon your hardware n others but highly recommended not to do. Another point as Andy mentioned your optimization may hurt you non-SharePoint dbs.
We have a fairly large number of non-SharePoint databases on the same instance as a SharePoint 2010 farm, and have seen no issues so far. We also have a number of customers running the same scenario with no issues.
There may be a performance impact on SharePoint due to the memory consumed by SQL caching other databases, and the maximum degree of parallelism (MAXDOP=1) setting that is required for SharePoint may impact the performance of other databases hosted on the same instance. As long as you provide SQL Server with enough memory for all of the databases being served, and the MAXDOP setting doesn't negatively impact the performance of the other databases, then you should be fine.
In an ideal world, the SharePoint databases will be on their own instance so you can tune that instance for SharePoint, and other instances for the workload that they are serving, however that's not always practical.